★ Regarding the iPhone Keyboard
Coming from the aptly-named BlackBerry enthusiast site CrackBerry, I was intrigued by this list of “Top 10 Reasons the iPhone Is No BlackBerry”. Never having used a BlackBerry, I don’t know as much about them as I’d like — I’m generally wary of spouting off regarding things I’ve never used. But this list is weak sauce. A few items are reasonable — e.g., video recording,1 VOIP for Wi-Fi, and GPS — but they’re also exactly the sort of...
-
★ The iPad
Back in December, here’s how I concluded my piece on what I expected from Apple’s then-still-unannounced tablet: If you’re thinking The Tablet is just a big iPhone, or just Apple’s take on the e-reader, or just a media player, or just anything, I say you’re thinking too small — the equivalent of thinking that the iPhone was going to be just a click wheel iPod that made phone calls. I think The Tablet is nothing short of Apple’s reconception of personal computing. After the iPad was announced, I got two types of emails from readers. The first group saying they were disappointed, because they had been hoping I was right that The Tablet would be Apple’s reconception of personal computing. The second group wrote to tell me how excited they were because I was right that The Tablet would be Apple’s reconception of personal computing. Count me in with the second group. Apple hasn’t thought of everything with iPad, but what they’ve thought about, they’ve thought about very deeply. I got mine Saturday morning, and I’ve been using it since — or at least as often as I could get it away from my son. Here are my thoughts. The Big Picture The whole thing feels fast fast fast. The only thing that feels slow overall, so far, is web page rendering. Not because it’s slower than the iPhone — it’s not, it’s definitely much faster — but because it’s so much slower than my MacBook Pro. It’s easy to forget on modern PC-class hardware just how computationally expensive HTML rendering is. The funny thing is, the iPad, in raw CPU terms, is a far slower machine than a modern Mac. But the iPad is running a lightweight OS and lightweight apps. It’s like a slower runner with a lighter backpack who can win a race against a faster runner wearing a heavier backpack. Thus, many of the things you do are faster, or at least feel faster (which is what matters), on the iPad than the Mac. Like, for example, launching applications. The built-in apps, and many of the third-party apps I’ve been using the most, are ready to use within a moment of launching them. (Games tend not to load instantly, but that’s true on high-power consoles like Xbox and PS3, too.) There’s something fundamentally strange about how fast the iPad feels considering how underpowered it is versus a modern PC or Mac. How can a computer with so much less CPU speed feel faster? What Apple has done is re-think several fundamental aspects. The iPad was designed from the ground up with a different set of priorities. I think Tim Bray summarizes it well: For a 1Ghz device with limited memory, the iPad is unreasonably fast. I suspect this accounts for a whole bunch of the “Wow!” reaction the iPad obviously provokes. Since there’s no free lunch, I think it’s really important that we understand what they sacrificed to get that performance. My bet would be on some combination of windowing and virtual memory. I tend to work on lots of things at once, but in fact I look at things in rapid succession, my eyes can really only focus on one thing at one time. Given sufficiently fast switching, maybe we all ought to be getting less WIMPy. The iPad (and iPhone OS across all devices) does indeed lack virtual memory. The only memory is honest-to-god RAM. RAM is fast, virtual memory is slow. The tradeoff is that without virtual memory, the iPad can do far less at once, but what it does do is never going to require hitting virtual memory. Without a windowing system, drawing is simpler and faster. Apple has made other significantly different tradeoffs as well. Battery life on the iPad is simply stunning. Reviewers across the board are getting real-life results that beat Apple’s promise of 10 hours of battery life. This is a function both of software (which does less and works hard to keep the CPU from drawing power while the iPad is being used) and hardware — iFixit’s teardown shows that, internally, the iPad looks more like a battery with a computer than a computer with a battery. The iPad, so far, never gets warm. Browse a bunch of web sites. Play some video. Play a game. It still feels as cool to the touch as when it’s turned off. It is also dead quiet — no fan, no humming, nada. This is the future of computing. The iPad was designed with an entirely different set of priorities than Macs or PCs. Someone may well produce a worthy iPad rival in the next year, but it’s not going to be something like HP’s Slate that runs Windows 7, an operating system that epitomizes the traditional set of computer design priorities. The iPad is also eminently affordable. $500 for this thing seems hard to believe. I wouldn’t hesitate to recommend it at double the price. But clearly there were tradeoffs involved to hit this price point. Build quality is not one — the thing feels perfect in hand. But it only has 256 MB of RAM — perhaps the single biggest hardware weakness of the device (see the section on Safari below). It is super high-quality, but clearly designed for the mass market. Anyone who thinks Apple only makes high-priced products has completely lost sense of reality. “Affordable luxury” is the sweet spot for mass market success today, and Apple keeps shooting bulls eyes. In fact, the only thing that makes my heart ache regarding the iPad is when I start imagining a hypothetical Pro model — imagine what Apple could put in an iPad that cost as much as a MacBook Pro. (My dream iPad Pro: double the display’s pixel resolution and include a gigabyte or two of RAM.) Affordability presents itself in other ways, too. Nothing is included in the box other than the power adaptor. The dock and case are separate SKUs, and it doesn’t even come with headphones. It’s like buying a Honda, not an Acura — the base model is not “well-equipped”. $500 is affordable but not cheap, and the iPad does not feel cheap in any regard. The build quality is outstanding. The brushed aluminum back makes my plastic iPhone 3GS feel cheap. The iPad takes more cues from the current iMacs than it does from the iPhone. The seam between the glass and the aluminum is nearly perfect. It’s just one piece of aluminum and a piece of glass — there is no superfluous chrome bezel between the glass and the backing as there is on all iPhones and iPod Touches to date. Even without turning it on it looks and feels a step beyond the iPhones and iPod Touches we’ve seen to date. The Killer App One thing that’s making it hard for some people to grasp the purpose of the iPad is that no one has an answer to what precisely it is for. This was not so for the iPhone. The answer to the question of what the original 2007 iPhone was meant for was right there at the bottom of the iPhone home screen, in the “dock”: phone, email, web, music and video. The other apps were icing on the cake. The four apps in the dock were what Apple designed the iPhone to do. The iPad also has a “dock” on the home screen, and the default apps in that dock are clearly important: Safari, Mail, Photos, iPod (which, on the iPad, is only for audio). But some are treating the iPad as, fundamentally, an e-reader. Others as a gaming device. Others as a movie player. None of those things are represented in the iPad’s default dock apps. The truth is that the App Store is the killer app. The iPad is meant for anything that can be represented on a 10-inch color touchscreen. Back in January when we were playing the “What’s Apple going to name the tablet?” game, my favorite, by far, was “Canvas”. I’m not saying here that Canvas would have been a better name than iPad, but the word conveys perfectly what the iPad is. Adam Engst captured this: The iPad becomes the app you’re using. That’s part of the magic. The hardware is so understated - it’s just a screen, really - and because you manipulate objects and interface elements so smoothly and directly on the screen, the fact that you’re using an iPad falls away. You’re using the app, whatever it may be, and while you’re doing so, the iPad is that app. Switch to another app and the iPad becomes that app. If that’s not magic, I don’t know what is. As did Cultured Code’s Jürgen Schweizer: Steve Jobs said about the iPod that “it is all about the music”. With the iPad, Apple has done the same for personal computing as it has done before with the iPod: it made technology go away. But if the device is gone, and the operating system is gone, what is left? The iPad is an empty canvas that invites us to imagine what is possible. It inspires our imagination and it makes us want to create, because never before were we able to create software that was so close to the user. The iPad hardware and OS are profoundly humble — they put all the focus on whatever app it is that is open. Out of Box Experience One thing that is very iPhone-like about iPad is that when you first take it out of the box, it wants to be plugged into your Mac or PC via USB and sync with iTunes. In some ways, that’s understandable. USB syncing is how you load your iPad with music and videos and transfer over stuff like your email accounts, and, if you’re not using MobileMe, your contacts and calendars. But, on the whole, it feels retrograde. It’s creates an impression that the iPad does not stand on its own. It’s a child that still needs a parent. But it’s not a young child. It’s more like a teenager. It’s close. So close that it feels like it ought to be able to stand on its own. Android devices do not have this problem. You can sync an Android device with a desktop computer via USB, for transferring things like music and videos, but you don’t have to. Out of the box, a Nexus One is ready to go. Google’s big advantage here is that they’re using online services as primary data stores. The Google Way is to use Gmail for email and contacts, and Google Calendar for events. You just tell your Android device your Google ID and password, and your email, contacts, and calendars start syncing over the air. Apple has MobileMe, but because it’s a paid service, they can’t (or at least won’t) assume that all iPad owners are going to use it. But then even those of us who do use MobileMe get stuck with a first-run iPad experience that involves a tethered USB connection to a computer. The Apple Way is to assume that your primary data stores for these things are locally stored on your Mac or PC — Address Book, iCal. At the very least, these things ought to be able to sync between iTunes (on your Mac or PC) and your iPad over your Wi-Fi network. Third-party iPhone OS apps like Things do a great job with this — there’s no reason iTunes and the iPhone OS shouldn’t too. Those Heart-Stopping ‘Scratches’ On the iPhone (and iPod Touch; assume from here out that when I say “iPhone” I’m referring to both), app icons on the home screen sit atop a plain black background. On the iPad, they’re spaced further apart, which is why I think Apple has added wallpaper — making the iPad home screen look a lot more like a Mac or Windows desktop. The default wallpaper shows a sunset skyline of a mountain range in front of a like. There’s a meteor shower in the sky. And the streaking meteors look, at a glance, like a series of severe scratches on the display. It’s a curious choice. The Touchscreen Keyboard It’s a lot like the iPhone’s, but, it’s different. Because it’s bigger, there are no pop-up indicators showing which key you hit as you type. They’re not necessary. The feel, overall, is pretty much like typing on a really big iPhone. If you’re in a position where you can set the iPad down on your lap or a table top, it’s not too hard at all to type with all your fingers when the iPad is in landscape (horizontal) orientation. Now, to me, it’s nowhere near as good as even the worst full- or nearly-full-size hardware keyboard I’ve ever used. You can’t just rest all eight of your fingers on the home row keys, and you can’t feel where the key cap edges are. You have to look at the keyboard a fair amount as you type. On a hardware keyboard, I hardly ever look at the keys. But for a touchscreen, it’s good. In portrait (vertical) orientation, I can type on the iPad using just my two thumbs, as I do on my iPhone. I have relatively large hands, though — I don’t think most people can do it. The keyboard in this layout is way too small for me to type with all of my fingers, though. In portrait orientation most people will type using one finger, I expect. Now, the funny thing is, in general, bigger keyboards are easier to type on than smaller ones. That’s why big laptops are easier to type on than compact ones, and, indeed, that’s why the landscape iPad keyboard on the iPad is easier to type on than the portrait one. But at a certain point, the curve flips around and smaller becomes faster. I type much faster on my iPhone using the smaller portrait orientation keyboard than the wider landscape keyboard. In both modes, I use just my two thumbs. With the smaller iPhone keyboard, my thumbs have to travel less from one key to the next. People who aren’t very proficient at the iPhone keyboard, or who have very large thumbs and therefore have trouble precisely tapping the smaller keys, may well prefer the iPhone’s wider landscape keyboard. But for me it’s not even close. I never type in landscape on my iPhone. And in fact (and this is the aforereferenced “funny part”), I type faster on my iPhone than I do on the iPad. That’s especially true for when the iPad is in portrait mode, which puts the keyboard size in a no-man’s land — too small to eight-finger-type, too big to thumb-type. But it’s also true for when the iPad is in landscape mode. I’m hopeful that this is just a factor of experience and muscle memory — I have nearly three years of experience typing on the iPhone, and only two days experience with the iPad. Last Friday I watched Andy Ihnatko eight-finger-type on his iPad — which he’d been using for over a week — and he was typing pretty goddamn fast. One problem I’ve run into is that Apple has subtly changed the layout of the keyboard from the iPhone’s. On the iPhone, the Delete key is on the lower right, above the Return key. On the iPad, it’s in the upper right corner, and the Return key is next to the L key. The iPad adds a right-side Shift key. The iPad layout makes perfect sense — both these keys are now where they reside on traditional hardware keyboards. Their weird positions on the iPhone are a compromise forced by the extreme lack of space on the iPhone display. Apple has also added a new key to the iPad keyboard’s numeric/punctuation mode: Undo. It’s a good idea — I have the feeling most iPhone users don’t know about the system-wide shake-to-undo gesture, and even for users who do, the iPad is harder to shake (and, when docked, downright silly to shake). But this new Undo key moves the period and comma keys over to the right by two positions. The iPhone keyboard layout is so firmly ingrained in my mind that these changes are problems for me — I keep hitting the (new to the iPad) right-side Shift key when I mean to hit Delete, and I keep hitting Undo when I mean to type a period. I’ll get used to it soon, I’m sure, but I find it interesting that my iPad typing muscle memory is based on the iPhone keyboard, not regular keyboards. I think this is because, overall, it really does feel like a big iPhone keyboard. Hardware Keyboard Support I don’t have (and did not order) the iPad keyboard dock, but I have been using an Apple Bluetooth keyboard. In fact, I’m using it to type this entire review. It works great. Pairing (via the iPad Settings app) is easy and quick. And it works great. Several essential text-editing shortcuts from the Mac OS work system-wide on the iPad: Command-Z, -X, -C, and -V work for Undo, Cut, Copy, and Paste. Command-A works for Select All. You can use the arrow keys to move the insertion point. Option-Arrow keys work to move the insertion point one word at a time. Command-Left/Right moves the insertion point the beginning/end of the current line; Command-Up/Down moves the insertion point the start/end of the current text field — which, in the case of something like Pages, is the beginning/end of the entire document. Holding down Shift extends the selection range, and works in conjunction with the Option and Command keys as expected. (Certain of Cocoa’s long-standing Emacs-style text editing shortcuts work too: like Control-K (kill) and Control-H (backspace).) Certain of the function keys on the Bluetooth keyboard are useful on the iPad. The brightness keys control the iPad’s display brightness. The volume (and mute) keys work. The playback buttons — play/pause, next, previous — all work to control the iPod app. By default, once you’ve started using a hardware keyboard, the on-screen keyboard no longer appears, which is great, because the full display is now available for displaying content. But if you want to use the on-screen keyboard while a hardware keyboard is active, you can toggle it using the hardware keyboard’s Eject key. The Esc key dismisses the auto-complete suggestion — it’s like tapping the little “x” next to the suggestion under the current word you’re typing. While a keyboard is connected, you can wake up the iPad by hitting any key — completely bypassing the iPad’s slide-to-unlock screen. Very nice. The iPad is fundamentally a touchscreen device. You absolutely do not need a hardware keyboard for it. But if you’re hoping to do any amount of serious writing with it (and, for obvious vocational reasons, I plan to), you’re going to want one. There are a few places in the iPad UI where I really wish the keyboard was useful but it isn’t. For example, Safari location field suggestions. On the Mac, you can use the up and down arrow keys to move through the list of suggestions. On the iPad, you must use touch to select from the list. Since you’re already typing if you’re entering a URL, this is just begging for arrow key support. (Ditto for suggested results from the Google search field in Safari.) The Esc key does not dismiss popovers, but that’s probably OK. It’s only possible to invoke popovers via touch, so it seems OK that you must dismiss them via touch as well. The Tab key can be used to switch between text fields; Shift-Tab goes in reverse order. (When using the hardware keyboard, I do find myself hitting Command-Tab, without thinking about it, when I want to switch to another app; it does nothing on the iPad.) Display The iPad display is, overall, wonderful. Colors are bright and (unlike the Nexus One’s OLED display) accurate. Photos and videos looks great. Touches seem precisely accurate. The glass feels good. Viewing angles are shockingly good. You can lay the iPad flat on a table while you eat or drink and it looks just fine at a decidedly skew angle — far more so than with the iPhone. This IPS stuff is the real deal; here’s to hoping for an IPS display in this year’s new iPhones. The only complaint I have about the display is that the pixel resolution isn’t all that dense. The iPad’s 1024  768 display has a resolution of 132 pixels per inch. The iPhone’s 640  320 display has a resolution of 163 pixels per inch. The difference isn’t huge, but it’s definitely noticeable. Type looks crisper on the iPhone than the iPad, and type rendering falls far short of even newspaper-caliber resolution, let alone glossy-magazine caliber. (Those of you who doubt that the pixels-per-inch resolution isn’t high enough, just wait until you see the type rendering on this summer’s new iPhones.) Safari The iPad is so good as a web reader, that, if you’re a web junkie, everything else the iPad does is just gravy. It’s good. I’m so used to Safari on the iPhone, though, where the toolbar is at the bottom, that I’m having a hard time getting adjusted to the toolbar at the top. I’m not saying it’s a bad decision on Apple’s part. In fact, the iPad HIG is quite explicit that iPad toolbars should go at the top, not bottom — which makes me think Apple thought about and tested this and has concluded that the top works better for the iPad form factor. It’s just that I use Safari on my iPhone a lot, and I am really used to the button placement. When you create a new page in Safari on iPad, text focus goes to the Google search field by default, rather than the URL location field. That’s a change from both desktop and iPhone Safari. I’m finding this hard to get used to, but I can see how this might be a better design for typical users. It makes the default search engine all the more essential to the web browsing experience, though. Zooming and flicking are essential to the experience, just like on the iPhone. Flicking is how you scroll, no surprise. The zooming, though, may come as a surprise. It wasn’t too long ago when 1024  768 was considered a large display for full-size web browsing. But: what matters on the iPad (and iPhone) is not the pixel count of the display, but the physical size. 9.7 inches diagonally is a bit small for non-zoomed web browser. But the action of zooming — whether through double-tapping or pinching — is so smooth, fast, and natural that it feels better, not worse, than old-school desktop web browsing. There’s one severe problem in Safari for iPad, though: memory crapping out. MobileSafari for iPhone has always allowed you to open up to eight pages at a time. It tries to keep them all truly open, in RAM, so that you can quickly switch between them. But when it runs out of memory it starts flushing some of the pages. It doesn’t forget the URL for those pages, and, in recent versions, it saves a static thumbnail image of the rendered page, but when you switch back to those purged pages, MobileSafari must reload the page — thus, you must wait both for the contents of the page to download and for the page to actually render (which — the rendering — often takes longer than the downloading). It’s very noticeable. Switching between unpurged Safari pages is instantaneous. Switching to a purged page takes as long as opening it from scratch. Wolf Rentzsch, linking to this complaint from Peter-Paul Koch, wrote a brief technical overview of why Apple might have designed MobileSafari this way. (Keep in mind that iPhone OS does not use virtual memory; thus RAM is severely constrained.) This purging problem got a lot better with the iPhone 3GS. The original iPhone and iPhone 3G only had 128 MB of RAM. The 3GS has 256. MobileSafari’s ability to keep more pages in memory is probably my single favorite aspect of the 3GS. The iPad also has 256 MB of RAM. But, in my use, iPad’s Safari isn’t able to keep nearly as many pages open as I can on my 3GS. In fact, sometimes it seems I can only have one, and every page I switch to gets completely reloaded. This is more than just annoying — it can lead to data loss if you have unsubmitted form data sitting in an “open” iPad Safari page. I’ve run into this posting items to DF from the iPad — my posting interface is a web page form. When I want to link to the current page, I invoke a bookmarklet which opens a new page with the title and URL fields of the posting form set to the title and URL of the page from which I invoked the bookmarklet. Often, though, I want to switch back to the page I’m linking to copy another URL or a bit of text to quote. Twice so far, when going back to the posting form, it’s been purged and must reload from scratch — in which case I lose anything I’ve already written. I never run into this problem on my iPhone 3GS when switching between just two open Safari pages. The problem is also severe for AJAX web apps, which tend not to be designed with full page refreshes in mind. I hope this can be improved significantly in an iPad software update, but I worry that it’s endemic — that because the iPad screen is so much larger than the iPhone’s, that MobileSafari must allocate significantly more memory per page for the framebuffers. 256 MB of RAM simply may not be enough for MobileSafari to keep more than two or three pages in memory. If so, Apple really needs to consider some sort of caching or serialization scheme rather than completely flushing away purged pages. Pages I wrote the entire 4,828-word first draft of this piece on my iPad using Pages.1 I didn’t use any of the formatting or layout tools — I used it as a text editor rather than a word processor. It’s quite serviceable. What I like best is that it opens very quickly. Switching between, say, Pages and Safari and back to copy-and-paste a URL feels more like switching than quitting, launching, quitting, relaunching. You don’t need to (and can’t) save manually. Whatever you do in a document simply persists automatically. When you go back to the list of documents, they’re presented as big thumbnails — very much like the list of open web pages in Safari. Pages’s toolbar and ruler are only visible when in portrait mode. In landscape mode, all of the chrome disappears. It’s just a full-screen editing view, a la WriteRoom. I’m writing this piece in this full-screen (landscape) mode, with my iPad propped up on a table in Apple’s iPad case. It’s a nice setup, and I can genuinely imagine leaving my MacBook at home for trips in the future, with the addition of few missing iPad apps (like, say, a good SFTP client). But when I say there’s no chrome in the landscape mode, I mean none. Pages has a decent simple little find and replace feature, but it’s only possible to invoke it in portrait mode. (I must have hit Command-F a dozen times so far, to no avail.) There are already complaints piling up that the iWork apps don’t support the complete feature set of their current Mac counterparts — open a file created in a Mac version of Pages/Numbers/Keynote on your iPad and certain document features may be removed. (The iPad apps prompt you with an alert telling you which aspects of the document have been changed or removed.) Another way of looking at it though, is that the iPad iWork apps are to their Mac counterparts what the iPad as a whole is to the Mac — simpler, more focused, but in some ways faster. Pages launches and is ready for input far quicker on my iPad than on my MacBook Pro. Writing this review, I’ve been switching back and forth between Pages and Safari. It doesn’t feel like quitting Pages, launching Safari, copying a URL, quitting Safari, and re-launching Pages. It feels more like switching — it only takes a moment after tapping the Pages icon on the home screen to be back where I was in my open document. (My only complaint is that you lose the insertion point when leaving and coming back to Pages — the document re-opens to where you left off, but you must tap the screen to place the insertion point. When switching several times, that becomes slightly tedious.) This is obviously not even close to a full review of Pages, but I can say without hesitation that it’s easily worth $10. Syncing There is, however, a severe shortcoming inherent to the iWork suite of iPad apps: document syncing between Mac and iPad. It’s a convoluted mess. In short, the only way to edit a document on your iPad that was created on your Mac, or vice versa, is to go through a convoluted multi-step process of exporting, copying, syncing or downloading, and importing. Ted Landau has copiously documented the entire situation in this article at The Mac Observer. Read it and weep. What it boils down to is that there is no syncing really. Real syncing is something like IMAP for email, or the way MobileMe handles calendars and contacts. When I read a bunch of new email messages using my iPad or iPhone, when I next sit down at my Mac, those messages are marked as read in my inbox. I don’t have to do anything on the Mac for that to happen. That’s just how IMAP works. I can add a new calendar event on my Mac, then walk away from my computer, take my iPhone out of my pocket, and the event is there. I can add a note to that event using my iPhone and a few moments later the note will be synced to the event on my Mac. Certain of my favorite iPad and iPhone apps sync like this too. When I read a bunch of RSS items using NetNewsWire on my iPad, they’re marked as read on my Mac. Sitting at my Mac in my office, I can send a long article to Instapaper. I go downstairs, pick up my iPad, sit on the couch, launch the Instapaper iPad app, and a few seconds later, there’s the article I just added to my Instapaper queue. This is the sort of data flow that makes me feel like I’m living in the future — using multiple hardware devices to view, edit, and modify the same data. I don’t worry about where separate copies of my data exist. Conceptually it’s just there in the apps, and the apps do all the hard work of pushing and pulling changes made on other clients. The data flow with these iWork apps isn’t like that at all, and needs to be for them to be truly useful. It doesn’t matter how good the user interface for viewing and editing spreadsheets is in Numbers for iPad if my spreadsheets aren’t there. Here’s an example. I keep the schedule for Daring Fireball RSS sponsorships in a Numbers document. What I’d like to be able to do on my iPad is launch Numbers and access the current version of that spreadsheet. But the only way I could possibly do that today would be if I went through the following steps every single time I made a change to the document on my Mac: Before opening the current version of the file on my Mac, check to make sure there isn’t a more recent version of it on my iPad. Open the file on my Mac and make changes. Save. Dock my iPad to my Mac via USB. Switch to iTunes and go to the Apps tab for my iPad. Add the newly-saved revision of the document to the file sharing list for the iPad’s Numbers app. Sync. Even after going through all of this, when I do want to open this file on my iPad, I have to remember not to open the last revision of it listed in the iPad Numbers app’s “My Documents” list, but instead remember first to import the latest revision from Numbers’s file sharing list to Numbers’ “My Documents”. And, again, it’s effectively up to me to keep track of which machine, Mac or iPad, has the most recent revision of the file. To say the least, this is a recipe for disaster, and even if you don’t make a mistake and inadvertantly make significant changes to an out-of-date version of the document on one of the two machines, you’re stuck with a preposterously, mind-bogglingly convoluted workflow each and every time you make a change to the document. The bottom line, obviously, is that there is no way that anyone is going to use these iPad apps in the way I describe above. As-is they’re only useful to me in two ways. First, I can imagine using Pages on the iPad to compose original new documents — posts for Daring Fireball — while I’m using my iPad. I’ll either finish them there and then copy-and-paste the result into the web-based posting interface for DF, or, I’ll send the draft to my Mac for further editing (which is what I did for the piece you’re reading right now). I can also imagine creating finished Keynote decks on my Mac and then moving them, once, to my iPad, and taking only my iPad with me to the presentation — i.e. using Keynote, Numbers, and Pages on the iPad as viewers for finished documents. (And, conveniently, they’re viewers that can make edits if you notice a mistake or want to make a last-minute change or addition.) But there’s no possible way to use these apps as clients alongside their Mac counterparts on an ongoing basis. The sort of over-the-air syncing I’m imagining for iWork is, admittedly, a difficult problem to solve. But the bad news for Apple is that their top competitor in this space has a solution: Google Documents. With Google Documents, there’s no making copies, importing/exporting, manually invoked syncing, or USB tethering involved if you want to edit a single instance of a spreadsheet from multiple machines. You just make changes on one machine, and when you next look at that document from another machine the changes are there. The workflow for iWork is downright antediluvian. It’s not just pre-Cloud, it’s pre-network. It’s effectively the “Who’s got the latest revision of this file?” workflow of the days when we moved files from one machine to another via floppy disks. What in the world is iWork.com for if not for solving this problem? At least iWork.com lets you avoid having to physically tether the two machines via USB to get a document from the Mac to the iPad (or vice versa), but it’s no better than file sharing through iTunes conceptually. When you send a file to iWork.com (from either Mac or iPad) you’re pushing a copy, a snapshot of the document from that moment. After making subsequent changes, you’ve got to push those changes to iWork.com all over again. And to get them on the other device, you must manually import — making just another copy. What you ought to be able to do is specify iWork.com as the canonical shared storage location for an iWork document. iWork.com doesn’t serve as any such purpose today. iPhone Apps I predicted it’d be crummy to run non-iPad-optimized iPhone apps on the iPad — like Classic apps running on Mac OS X — and I was right. It’s OK for games — they look jaggy, but jaggy games aren’t that uncommon. But regular (non-game) apps just look and feel weird. When you run them pixel-doubled text doesn’t scale dynamically — everything is pixel doubled. It’s a good way of proving that the iPad is not “just a big iPhone”, though. The only iPhone app I find myself using on my iPad is Simplenote, for copying and pasting bits of text to and from my Mac and iPhone. Needless to say, I’d love an iPad-optimized version of Simplenote. iBooks and Kindle The iBooks app is free, but doesn’t ship with the iPad by default — you have to download it from the App Store. Apple hasn’t explained why this is so, but there are several reasons I can think of. For one thing, e-book rights are managed on a country-by-country basis — it seems likely that the iBooks store won’t be available in every country where the iPad will soon be sold. Making it an App Store app will also allow Apple to update the app on its own schedule — built-in system apps only get updates along with the entire system. So in some ways, the iBooks app is on equal footing with other e-book readers available in the App Store, particularly Amazon’s Kindle app. But iBooks does get some special treatment — the first time I launched the App Store app on my iPad, it prompted me with a dialog box asking if I’d like to down the free iBooks app. It’s impossible to miss. The iBooks app also has display brightness controls that are not availble through public APIs. Winnie the Pooh is included as a free sample, and the choice is genius — it’s a beloved story, a good read, and best of all (from Apple’s perspective) it can’t be read properly on the Kindle because the color illustrations are a big part of the experience. No book on the Kindle will ever look this good. The Kindle has its own advantages — its books are generally cheaper, its selection bigger, and e-ink works better in bright sunlight — but Winnie the Pooh epitomizes the iPad’s advantages. iBooks’s page-turning animation is delightful — it doesn’t just track your finger-swipe precisely, but even renders the type faintly in reverse on the other side of the “sheet”. The practical minded can simply tap the right and left edges of the screen to turn pages. Amazon’s iPad-native Kindle app is good, too. Oddly, to my mind, it is superior to their recent Mac app in every way. It looks better, feels better, renders text better, and has more features. I say this is odd because the iPad was announced just two months ago; Mac OS X was announced over a decade ago. I suspect part of the reason the Mac version is so crippled is that they were more worried about keeping Mac users from un-DRMing Kindle content than they were about making the Mac app an actual good-to-use app. The Kindle doesn’t do animated page-turning, but that’s not a big deal. Reading is great. And the Kindle’s ace-in-the-hole, of course, is the far larger selection of e-books in its store — hundreds of thousands versus Apple’s tens of thousands. I bought When the Game Was Ours, a new book by Larry Bird and Magic Johnson. It is not available in the iBooks store. So Kindle’s advantage is library size (and, secondarily, price per title). iBooks’s advantage is the color display. I’d be shocked if every single piece of advertising Apple produces for iBooks doesn’t focus entirely on screenshots of books with color illustrations, photos, and video. I think it’s going to be easier for Apple to improve the iBooks store library than it will be for Amazon to create a Kindle hardware model with a color display. I think Amazon would do well to add color support to Kindle e-books for use on iPads and iPhones. Kindle has a better chance of long-term success as a software platform than a hardware one. Third-Party Apps in General Given that most iPad-native apps in the store right now were developed using only the simulator by developers without access to actual iPads, you might expect apps to be buggy and UIs to be awkward. I’ve found the bugginess to be true, but the UIs are actually good. I think the physical prototypes developers jury-rigged for themselves paid off, design-wise. There’s no question that UIs are going change rapidly in the coming weeks now that developers have the real deal to measure the feel of their apps against, but for the apps I’ve been using the most, they’re pretty damn good already. As for the bugginess, I’m not saying it’s inexcusable or even surprising — the SDK simulator is not a perfect simulation. Several of the bugs I’ve reported are only present when the apps are running on actual iPad hardware. On the whole, though, the quality of iPad apps on day one is better, by far, than I had expected considering that developers had to build them in the dark, as it were. Prices, so far, are significantly higher than for iPhone apps — but still far cheaper than category equivalent Mac apps. For example, NetNewsWire is $10 (and going to $15 in May); Things is $20; and OmniGraffle is $50. No doubt there are going to be wildly popular 99-cent iPad apps, but it’s also shaping up as serious platform for serious tools. Games are a bit more expensive, too, but, to me, reasonably so. The final word count is just short of 7,300, so admittedly I wound up writing quite a good chunk of it in BBEdit on my Mac.↩
-
★ BlackBerry vs. iPhone
1: Wherein Neither ‘RIM’ Nor ‘BlackBerry’ Are Even Mentioned, but Rather the Stage Is Set for Showing Why They Might Be Seriously Screwed Along the lines of can’t-really-be-answered-but-gosh-they’re-fun-to-ponder questions like, say, “Who’d win in a fight, Batman or Spider-Man?” or “Star Destroyer vs. U.S.S. Enterprise?”,1 here’s one regarding the iPhone: What historical Mac is a current iPhone most analogous to, spec-wise? I.e, complete this sentence: “An iPhone is like having a tiny ____ in your pocket?” Now of course the comparison can’t be precise. Different software, different use cases, different purposes. But there’s no denying that an iPhone is a computer. And unless you’re really young, it’s faster — a lot faster — than the computers you owned not so long ago. So, seriously, stop here for a moment and think about it. My first answer, pulled simply from recollection of how fast machines felt to use, was the original iMac. But that machine — announced 10 years ago this week — had a 233 MHz G3 and, by default, a paltry 32 MB of RAM. Apple has never officially released the CPU specs of the iPhone, but Craig Hockenberry poked around with undocumented system APIs which indicated the iPhone’s CPU runs at 400 MHz with a bus speed of 100 MHz, and that there’s 128 MB of RAM. As we all recall from the PowerPC era, MHz is not a precise metric for comparing the performance of CPUs across different architectures; I wouldn’t be surprised in the least to find out that a 400 MHz PowerPC G3 is a faster chip than the 400 MHz ARMwhatever that’s in the iPhone, if only because of the power constraints. But, still, it’s something. So, my answer to the question: the original “Pismo” G3 PowerBook. The numbers match up pretty closely: 400 MHz CPU, 100 MHz bus speed, 64 MB of RAM. (The higher-end Pismo had a 500 MHz CPU and 128 MB of RAM.) Even storage sizes are similar: hard drive options for the Pismo were 6, 12, or 18 GB. Another possible answer: the original blue-and-white Power Mac G3 — again, 400 MHz CPU, 100 MHz bus speed, 64-128 MB of RAM, and 6-12 GB hard drives. Think about that — in just nine years, the specs that then described Apple’s top-of-the-line desktop computer now describe their phone. One thing that makes this comparison hard is that there’s not much software in common. You can’t use most of the real-world tasks commonly used for ballpark benchmarking, like, say, Photoshop image processing or ripping MP3s from AIFFs, because the iPhone doesn’t do them. But there is one processor intensive task we can compare: web page rendering. In the early days of the web, it took a while for even moderately large web pages to render in a browser, even when you were loading them from HTML files right on your hard drive. If you were to plop yourself down in front of one of these vintage 1999-2000 Macs for an afternoon of web browsing, even with a decent Ethernet connection to the Internet you’d find the experience pretty damn slow by current standards. For all the incessant chatter about the demand for and purported certainty of 3G wireless networking in the next generation of iPhone hardware, the truth is that current iPhones are held back, web-surfing-wise, by more than just the speed of EDGE (which admittedly, is indeed pretty slow). Recall this video pitting a 3G Nokia E61i against an iPhone on EDGE — total rendering time was more or less the same, and in a few cases, the iPhone came out ahead. You can see that browsing speed — which is what matters — depends on more than just networking speed simply by comparing how long it takes to render a web page on the iPhone using Wi-Fi: a lot longer than it takes to load the same page in using Safari on a Mac. For example, it takes about two or three seconds for Safari to load the Daring Fireball home page on my new MacBook Pro. Using the same Wi-Fi network, it takes my iPhone about 15 seconds. (Using EDGE, it takes about 60 seconds to completely load, although you can start reading much sooner than that.) Point being that even if 3G wireless networking were as fast as Wi-Fi — which it’s not — browsing on an iPhone would still be pretty slow compared to browsing on a modern desktop or laptop. If you frequently use Wi-Fi on your iPhone, a faster processor in the next-generation hardware would make a bigger difference to the overall experience than faster phone-carrier networking. And so here’s the point I’m driving at. If a 2007 iPhone is loosely equivalent in terms of computing power to a 2000 PowerBook or 1999 Power Mac, that puts the spread at around seven or eight years. Extrapolate forward, and it’s therefore not at all unreasonable to think that a 2014 iPhone will pack the computing power of today’s MacBook Pro. Or, nearer term, that an iPhone introduced two years from now might pack the punch of a 2003 Aluminum PowerBook G4 — quite a difference from the Pismo. Even if your estimate of the iPhone’s equivalent-horsepower Mac is further back in time than mine, there’s no denying that Moore’s Law applies to handhelds, too. Eventually there will be a computer that fits in your pocket that is more powerful than today’s Mac Pros. But the path from here to there is riddled with difficult engineering problems — heat dissipation, battery life, and OS integration chief among them. There is marketing. There most certainly is design. But at the core of this market — by which I mean the market for handheld multitasking web-surfing networked-everywhere “phones” which are really computers — is engineering. Apple is the best handheld computer engineering company in the world today, hands down. They’re also the best handheld computer user experience design company. And they’re not sharing. 2: Why RIM Is Screwed When the iPhone was announced, I saw Apple as staking out ground far afield from the territory RIM occupies with the BlackBerry. Last year, I didn’t see Apple implementing Exchange support in the iPhone OS, and clearly that was, well, completely wrong. The “enterprise” features Apple has announced for the imminent 2.0 release of the iPhone OS — remote wipe, push email, automatic calendar and contact synching — pretty much encompass every single feature that’s been held up as a reason the iPhone wouldn’t sell to enterprise users. It remains to be seen how well these new iPhone features will actually work, but if the answer is “as well as promised”, and if the iPhone’s Mail app is improved in ways targeting people who receive a high number of messages, it’s hard to see a single software advantage in the BlackBerry’s favor. Which leaves hardware, which leaves the keyboard. Two Sundays ago, the New York Times ran a lengthy business-section piece by Brad Stone, titled “BlackBerry’s Quest: Fend Off the iPhone”. Regarding the upcoming BlackBerry 9000, the focus turned to the keyboard: Photographs of the device, leaked to gadget news sites, also indicate that the new BlackBerry will have elegant curves suggestive of the iPhone. It will also have a physical keyboard like previous R.I.M. devices, as opposed to the glass touch screen found on the iPhone. There’s a reason that R.I.M. is averse to the iPhone’s glass pad. “I couldn’t type on it and I still can’t type on it, and a lot of my friends can’t type on it,? says Mike Lazaridis, R.I.M.’s co-chief executive and technological visionary. “It’s hard to type on a piece of glass.? Mr. Lazaridis thinks that e-mail-dependent BlackBerry owners demand the reliability and tactile feedback of a keyboard. But, despite his critique of the iPhone, he does not dismiss the possibility that R.I.M. may itself one day sell a touch-screen phone, aimed specifically at consumers without the e-mail demands of BlackBerry’s core users. Translation: “We’ll emphasize the physical keyboard as a differentiating factor as long as it seems to work, at which point we’ll try a touch-screen keyboard too.” The only other angle RIM seems to be hanging its hat on is “security”: RIM is also betting on security, which hinges on the fact that its handsets and e-mail systems are relatively impervious to hackers. Mr. Lazaridis predicts that corporations will not give iPhones to their workers because they have already proved vulnerable to hackers eager to pry iPhones off AT&T’s system and make them work on other wireless networks. “It’s not that simple for an I.T. manager to give up security,? he said. The idea that iPhone carrier unlocking is a “security problem” is a conflation between what an attacker can do to your phone, against your will and/or unbeknownst to you, versus what a phone’s owner can do to their own phone. It’s not like these “hackers” are attacking happy AT&T-subscribed iPhone owners and switching them over to Sprint against their will. To understand why Apple is making a concerted effort to appeal to BlackBerry users, consider an analogy to the board game Risk. RIM has a large army (read: users), but they’re all massed together in one spot on the map. They care about email, they care about exactly the sort of enterprise features Apple has announced for the iPhone, and they are known to be willing to pay several hundred dollars for a handset. A lucrative target that can be attacked all at once. And the BlackBerry is weakest where the iPhone is strongest: web browsing, music, and video. Compare and contrast with, say, a software platform like Windows Mobile, or a hardware maker like Nokia — their users are spread across a wide variety of phones and platforms. It was far easier to turn the iPhone into something almost every BlackBerry customer might at least consider than it would have been to make a lineup of iPhones that appeal to every Nokia customer. RIM doesn’t really have any lock-in other than user habits. The BlackBerry gimmick is that it works with the email system your company bought from Microsoft. Replace a BlackBerry with an iPhone (2.0) and the messages, contacts, and calendar events that sync over the network will be the same ones on the BlackBerry you just tossed into a desk drawer. In broad terms, BlackBerrys are optimized first for email; the iPhone for the web. What’s more important, an email client or a web browser? For most people, and perhaps even most current BlackBerry users, the answer is clearly the web. Many people in fact read their email entirely through the web. Unless you’re Richard Stallman, you probably don’t read the web through your email client. The iPhone would be a credible, useful device with just two apps: Phone and Safari. But it doesn’t just have those two apps. It has a slew, and they’re all better on the iPhone than the BlackBerry and the difference with regard to anything other than email is only going to get more stark once the iTunes App Store opens its doors. If nothing else, consider games, games, and games. As I wrote when the iPhone’s upcoming enterprise features were announced, the iPhone can do more BlackBerry-ish things than the BlackBerry can do iPhone-ish things. Apple doesn’t wait for someone else to knock one of their hit products off its throne or slowly run it into the ground (cf. the Motorola Razr) — they do it themselves. For six years pundits have been declaring that competitors would “soon” catch up to the iPod, but the iPod has never been a static target — over the same six years Apple has released significant new iPods every year. There are no signs that RIM has the engineering chops on either side of the ball — hardware or software — to compete with where the iPhone is now, let alone where it’s going to be. We know that Apple has an OS that can scale to take advantage of faster (and multi-core) processors, because OS X is doing that already. If a two-years-away 2010 iPhone might be like having a 2003 PowerBook G4 in your pocket, for RIM’s sake a 2010 BlackBerry had better be something more than a BlackBerry with a brighter screen. Correct answers: Batman, Star Destroyer.↩
-
★ 4
The first thing you notice is that the iPhone 4 feels smaller in hand — the decrease in width, even more so than thickness, is quite noticeable. It feels tight. Then you turn it on, and you see the screen. Apple seems very confident about the precise size and dimensions of the iPhone display: 3.5 inches, with a 3:2 aspect ratio. Not 3 inches. Not 4 inches. In fact, Apple seems very confident regarding everything it decided for the original 2007 iPhone. There are no new buttons, or even moved buttons. The Retina Display is emblematic of the iPhone 4 as a whole, both hardware and software: the same fundamental idea as the original iPhone, but clarified. It hasn’t really changed so much as improved — like the same picture in increasingly sharper focus. As I wrote after examining Apple’s iPhone 4 demo units after the WWDC keynote, the Retina Display’s overall effect is like that of high-end glossy magazine print — except that it updates live. It’s living breathing print. I don’t recall ever having seen motion graphics of this resolution, anywhere. And (again as noted previously) it’s more than just the pixel resolution — it’s that the LCD is so much closer to the surface of the glass. Like pixels on glass rather than pixels under glass. This is the result of a new manufacturing process Apple has pioneered. No other company gives a shit about things like this. The iPhone 4 feels like a major step toward an idealized iPhone form factor. What defines the iPhone, physically, is the 3.5-inch diagonal screen. The iPhone 4, in terms of width, seems about as narrow as you could possibly want it to be without reducing the size of the display itself. There’s just enough of a bezel around the sides to avoid inadvertent touches from fingers holding the phone by the edge. My older iPhones now feel swollen along their rounded edges. And yet somehow, despite making the form factor noticeably smaller, Apple made room internally for the battery to be bigger. In my review of the iPhone 3G two years ago, I wrote: The home button on the 3G seems to require a more forceful push. The clickiness of my original iPhone’s home button is better. On the other hand, the clickiness of the 3G’s volume and sleep buttons is better. Apple sometimes seems to be the lone consumer electronics company that pays any attention at all to the tactile response of buttons. The iPhone 4’s buttons are improved all around. The Home button restores the clickiness of the original iPhone’s. The new volume buttons, silence toggle, and power button all have a better feel than ever before. Apple is so good at making buttons, it’s almost enough to make one wish they made button-laden devices. The overall build quality seems impossibly good. The iPhone 4 is beautiful to behold and feels like a valuable artifact. It’s like a love letter to Dieter Rams. The Flat Sides The flat sides make it feel much more like a real camera — a decidedly thin camera, but a camera nonetheless — while taking pictures. This improvement is equally noticeable when holding the camera horizontally for any reason — like, say, to watch video. When you’re holding a phone vertically, you’re typically cupping it in the palm of one hand. But when holding a phone horizontally, you typically pinch it between your forefinger and thumb. The iPhone 4’s flat sides make this grip far more secure. Performance The iPhone 4 is definitely faster than the 3GS, but it doesn’t feel to me as though the difference is as noticeable as last year’s leap from the 3G to 3GS. This video on YouTube, which compares the startup time for Plants vs. Zombies on an iPhone 4, iPhone 3GS, and original iPhone, feels exactly right to me: the 4 is noticeably faster than the 3GS, which in turn is way faster than the original iPhone (and the 3G, which performance-wise was nearly identical to the original). The big win for Apple’s A4 system-on-a-chip, I suspect, is not raw performance (even though it is faster), but rather performance-per-watt. It’s an even better balance between speed and power consumption. And, on a related point, the A4 system is physically smaller, which has enabled Apple to reduce the size of the iPhone form factor and still include a bigger battery. Battery life seems a tad better on the iPhone 4 than the 3GS, which is saying something, given that the CPU is faster and the Retina Display packs four times as many pixels, is brighter, and offers a better contrast ratio. Typing on the iPhone 4 keyboard seems better than ever. The increase in performance has made the iPhone 4 more responsive to touch events, and for me this is most evident while using the keyboard. The increase in RAM from 256 to 512 MB is, no surprise, welcome. More web pages remain in memory in MobileSafari, and more apps remain resident in memory for fast app switching. The combination of more RAM and iOS 4’s new fast app switching makes the process of switching between a handful of apps feel like an all-new experience compared to older iPhones running OS 3. The Glass Back Both aesthetically and tactilely, the iPhone 4’s glass back is very pleasing. It has a 2001-monolith-like symmetry. But as a heavy iPhone user since day one, I’m finding it slightly disconcerting. I’ve always carried my iPhone the same way: front right pants pocket, with the glass toward my body, so that if my leg hits something or something hits my leg, the back of the iPhone would take the impact, not the glass. Now it’s glass on both sides, and what keeps happening is that I reach into my pocket to take it out, my fingers feel the smooth glass facing out, and I think, “Shit, I pocketed my iPhone wrong last time.” I’ll get used to it shortly, I suppose, but there’s really no way to distinguish the front from the back by touch other than to find the Home button or speaker. And, for obvious reasons, the glass back raises concerns about the iPhone 4’s droppability. With previous iPhones, it was liking dropping a piece of buttered toast — there was a lucky and unlucky side on which it could land. With the iPhone 4, it’s like dropping a piece of toast that’s been buttered on both sides. FaceTime I don’t really talk on the phone that much, but I’ve had fun trying out FaceTime with a few iPhone 4-enabled friends. It truly is delightfully easy to initiate, whether by starting with a voice call or not. The video quality is far smoother than anything I’ve ever gotten using Skype or over AIM with iChat — better resolution, far fewer compression artifacts, and almost no pauses or lag. It’s early in the game, but so far FaceTime seems best-of-breed technically. Audio quality over FaceTime is excellent. This is particularly noticeable with calls that start using voice. The difference is so stark that it makes me wish FaceTime could kick in for audio-only calls between FaceTime-capable phones. AT&T should be ashamed. Portrait orientation looks perfectly natural for FaceTime, for the obvious reason that it frames the face like — duh — a portrait. When you initiate a FaceTime call directly — by clicking the “FaceTime” button on a contact — you get an iChat-sounding “ringer” sound while waiting for the recipient to accept the call. If the recipient is not available for FaceTime (e.g. if their device is not currently connected to Wi-Fi), they will get a “missed FaceTime” notification pretty much just like what you get when you miss a phone call. This includes a notification alert on the lock screen, and an increase to the number in the Phone app’s red badge. Voicemail would be great for these missed FaceTime-only calls, but it’s not there. (“Facemail”?) When you switch to the home screen or another app during a FaceTime call, the video pauses, but the audio continues. Once you switch a call to FaceTime, you can’t switch back to voice-only, but switching to another app while the call continues effectively turns FaceTime into voice-only. That FaceTime goes through the Phone app, rather than a dedicated FaceTime app, makes me wonder what Apple will do if I’m right that this year’s upcoming new iPod Touches will be FaceTime-capable. My guess is that it’ll be sort of like with the iPhone’s “iPod” app, which on the iPod Touch is split into separate Music and Video apps: on the iPhone, FaceTime is subsumed by the Phone app, but on the iPod Touch, it could be its own standalone app. It’s no surprise that FaceTime, not the Retina Display, is apparently going to be the centerpiece of Apple’s TV ads for the iPhone 4. It is instantly compelling. It’s also the sort of thing that drives critics of Apple products nuts. “Look at these stupid people who think Apple invented video chat, or even mobile video chat.” Right? What they’re overlooking, and will always overlook, is the value of the “It just works” factor. Normal people aren’t just going to use FaceTime — they’re going to love it. And if it really takes off, it’ll turn FaceTime into a de facto social network. People will buy iPhone 4’s (or other future FaceTime devices) because two or more of their friends have them and they feel like they’re missing out. Mark these words: FaceTime goes down as one of the most important things Apple has ever introduced. Helvetica Neue It’s a subtle change, but Apple has changed the system font for the iPhone 4, from Helvetica to Helvetica Neue. The change is specific to the iPhone 4 hardware (or more specifically, the Retina Display), not iOS 4. On older iPhone hardware, iOS 4 still uses Helvetica as the system font. If you think it’s hard to tell Helvetica apart from Arial, this one’s going to shoot right over your head. Helvetica Neue isn’t so much a different typeface as a “reworked” version of the same face. Here’s an overview of Helvetica’s history from U&LC. (And a pronunciation thread on Typophile.) Says my friend and fellow Helvetica aficionado Mike Monteiro,1 “In comparison to Helvetica Neue, Helvetica looks ungainly. It’s 95 percent there. Neue took it the other 5 percent.” In general, where Helvetica Neue differs from regular Helvetica, its glyphs are slightly wider and rounder. The most telling difference, to my eyes, is the uppercase bold M: A good place to spot the difference, side-by-side with an older iPhone or iPod Touch, is the “AM/PM” in the status bar. On the iPhone 4, it’s clearly Helvetica Neue (with the wider M), and on an iPhone 3GS running iOS 4.0, it is regular Helvetica. Aesthetically, this change is a win. Helvetica is a great typeface; long-time DF readers know I’m a huge fan of it, and the choice to use it for the iPhone’s system font is one of my favorite decisions in Apple history. But Helvetica Neue, subtle though its differences are, is a nice improvement. It is a more Helvetica-y Helvetica. Why change only on the iPhone 4, though? I suspect it’s because Apple’s digital version of Helvetica is better hinted for on-screen rasterization than Apple’s Helvetica Neue, which makes it look slightly sturdier on the relatively crude pre-Retina Display iPhone screen. I.e., Helvetica looks better than Helvetica Neue on older iPhones, but Helvetica Neue looks better on the truly-print-caliber Retina Display. In the old days, there was print (high resolution) and screen (low resolution), and a wide resolution gap between them. The iPhone, and devices with similar pixel density, introduced a sort of middle ground — many print fonts that never looked good on screens before looked good on the iPhone. The iPhone 4, however, offers type rendering that is legitimately print quality. That Apple pays so much attention to the details as to pick a different version of Helvetica for different classes of displays is emblematic of what makes the iPhone the iPhone — software and hardware that are designed in tandem as parts of a single whole. Helvetica Neue’s Missing Italics There is, however, one problem with Helvetica Neue in iOS 4.0: it doesn’t include italics. You can see this for yourself on this web page I’ve created that specifies Helvetica and Helvetica Neue alongside each other, including spans of bold, italic, and bold italics. Here’s how that test page renders in the following browsers: Safari 5 on Mac OS X 10.6.4 iPad running iOS 3.2 iPhone 3GS running iOS 4.0 iPhone 4 running iOS 4.0 It renders correctly on the Mac and iPad, but on both iPhones, the italic and bold italic variants of Helvetica Neue are not available, and render as non-italic. I can only assume this is an oversight on Apple’s part. It affects iPhone developers who use the italic system font in their applications — in all previous versions of iOS (née iPhone OS), [UIFont italicSystemFontOfSize:] returned an italic font; in iOS 4.0 it does not. The iPhone’s OS has long included several non-italic weights of Helvetica Neue. The iPad’s OS (version 3.2) was the first to include the italics. But iOS 4 only includes the same non-italic weights of Helvetica Neue from OS 3.1 and earlier. (Yet another sign of the divergence between the iPad’s and iPhone’s software.)2 I’ve filed a radar on the issue, requesting that Apple add the italic weights of Helvetica Neue to a near-future iOS update. The iPhone should include all the same fonts as the iPad. (Those of you with Apple developer accounts who agree should file duplicate radars.) Camera I thought last year’s 3GS provided a nice improvement to the iPhone camera, with superior still photos and the addition of video. The new (primary) camera in the iPhone 4 is a bigger improvement. Still photos are of the quality of a low-end dedicated point-and-shoot camera, and the 720p video is surprisingly good. Here are a handful of stills and a video I took over the weekend — none of them post-processed in any way. The iPhone 4 adds a flash to the main camera. I suppose that’s nice, for when you absolutely can’t get a decent exposure in low light without it, but the new camera is sensitive enough that you can take pretty good photos in relatively low light without it. I’ve turned the flash on mine off, and don’t expect to turn it on more than a handful of times. Is the video quality just as good as a dedicated 720p video camera like the Flip HD? I say yes. And at the very least, it is very close. Most impressively, video shot with the iPhone 4 doesn’t seem to suffer from any sort of lag or stuttering, even while panning or walking around. Playback, needless to say, is silky smooth. More importantly, Flip-class cameras don’t offer online connectivity, and don’t offer on-device editing like the iPhone 4 does with iMovie. Flip’s not dead yet, because you can get an HD Flip for about $120. One can imagine sending a class of six-graders out armed with a few school-owned Flips; that’s not going to happen with $499 iPhones. But my guess is that we’re going to see a similar camera in this year’s new $299 iPod Touch, which will be next year’s $199 iPod Touch. I think Apple is going to be able to get the price on such an iPod Touch below $200 before Cisco is going to create iMovie-like editing software for the Flip. It’s hard to overstate just how many wildly variant devices the iPhone and iPod Touch compete with. Phones and handheld audio/video players, yes, obviously. But now also cameras and handheld game consoles. It’s an old adage that the best camera is the one you have with you. It’s getting to the point now where the iPhone camera isn’t just good because it’s with you, but good because it’s actually pretty good. The Reception and Proximity Sensor Problems There are two widely-reported problems with the iPhone 4. First is the issue surrounding 3G reception and hand placement on the device. There’s no doubt that this is an issue for many — but I think a minority — of iPhone 4 owners. I haven’t been able to duplicate the problem on mine, though. Sometimes, but rarely, I can make it drop a single bar, but I can’t duplicate the drop to “No Signal” that many others can. Best as I can tell, based on the reports I’ve read, including many emails from DF readers, the problem is multivariate. It definitely seems related to signal coverage (or cell tower proximity, or something like that). I’ve received many emails (and a few tweets) from DF readers who can reproduce the problem at will in one location, but can’t in another. Not much help, though, when the problematic location is, say, your home or workplace. But I’ve also heard from a few readers with fellow iPhone 4-owning friends and colleagues, who’ve been able to test several units side-by-side. Some iPhone 4 units seem more susceptible to the problem than others — which makes me question whether this is something a software update can address. I think it’s like a combination of software and manufacturing. The other issue regards the proximity sensor — the sensor which turns off the touchscreen when you hold the phone to your head for a call. The proximity sensor on the iPhone 4 seems far more sensitive than on previous iPhones, such that minor movements away from your head during a call re-enable the touchscreen, which then leads to your cheek inadvertently engaging the Mute or End Call buttons. Here’s a description of the problem at EverythingiCafe; and here’s a 24-page (!) thread about it on Apple’s discussion forum. This problem, I have seen myself. My cheek invoked the End Call button during a call yesterday, something that I don’t recall ever having happened in the three years I’ve been using iPhones. Garrett Murray is afflicted by both these problems. It’ll be interesting to see whether Apple is able to address either or both of these problems via a software update. And, if so, when? The iPad was released in April and still hasn’t seen a single software update. (Perhaps the iPad is an exception, and Apple has decided against a 3.2.1 iPad update to devote all of its iPad OS development time on iOS 4.1.) The proximity sensor issue strikes me as more likely to be fixable via software. As for the reception issues, I can see this playing out three ways: Best case: It’s fixable, or at least improvable, via software changes alone. OK case: It’s a manufacturing issue that Apple can address going forward, with future production runs. Apple has sold a lot of iPhone 4’s already, but most of the iPhone 4’s they’ll eventually sell haven’t yet been made. They might take a small hit on exchanges from existing iPhone 4 users who are seeing the problem. Worst case: It’s inherent to the design of the iPhone 4’s novel external antennas, and all iPhone 4 units will be susceptible to the problem. As I stated before, some people seeing the problem can’t reproduce it (or at least see lower amounts of signal loss) when they try using a different iPhone 4 unit in the same location. That suggests it’s fixable, but perhaps only in manufacturing, not in software for existing units. And even in the worst case scenario, it only seems to be a problem when holding the phone in certain ways while in areas of marginal signal strength. That’s not to pass the blame from Apple to AT&T, but only to say it’s far from catastrophic. It may wind up being more of a publicity problem than a technical one. At the very least it isn’t going to help the iPhone’s perception as a great device but weak phone. Monteiro uses Helvetica Neue in this excellent series of paintings.↩ Also goes to show that iOS developers should be specifying the font for UI elements via API calls for the “system font”, rather than hard-coding for “Helvetica”. But according to the Apple’s iOS 4.0 release notes, “References to the Helvetica font in nib files will be decoded as the system font on these newer devices.” That said, I’ve noticed a few spots in iOS 4 where you still see Helvetica rather than Helvetica Neue; e.g. the “All Contacts” list in the Contacts and Phone apps, and the Phone app’s Recent calls list. (The Phone app’s Favorites list, however, uses Helvetica Neue.)↩
-
★ This Apple-HTC Patent Thing
There are two aspects surrounding Apple’s patent litigation against HTC that demand further consideration. First, the severe problems with the U.S. patent system as a whole, particularly with regard to software patents. Second, the strategic implications of Apple’s decision to file suit. Smart writers with first-hand experience with software patents have written much over the past few years on the system itself. Tim Bray, in particular, has written extensively on them, including his own experience obtaining them. I’ll quote here from one of his early pieces on the subject: Are Software Patents a Broken Idea? — I really don’t know. One of my brothers, an Industrial Designer, has his name on a patent for a device for mixing gases that’s used in chromatographs. When he showed me the filing, with the drawings and schematics and so on, I was impressed; these guys had cooked up a new arrangement of valves and geometries that did a practical task in an elegant and new way. It felt much more rigorous than the way we go about inventing new technology in the software space; but maybe that’s just because I’m way too close to the software world and can see all the warts on its underbelly. I’m inclined to think there’s a spectrum of reasonability in software patents. “One-click ordering” seems like a grievous error, simply because if you said those three words to any web-savvy ecommerce-savvy programmer, they’d say “OK” and build it for you and it would work; which doesn’t seem to meet a high enough bar to qualify as an invention. But consider the basic PGP setup by Phil Zimmerman, it’s just immensely clever and elegant. I have the feeling that that really does qualify as an invention in totally the same sense as my brother’s gas-mixing apparatus. Obviously I think the things I filed are closer to PGP than one-click ordering. In a later follow-up, Bray wrote: Does this mean that I’ve concluded that software patents are just fine, thank you, and the current rat’s-nest of litigation is good business practice? No; while I generally agree with Jonathan that the software-patent idea is not inherently broken (and thus disagree with Richard Stallman), the fact is that it’s almost impossible for rational people to have a rational discussion about software patents. The reason is the insanely-dysfunctional behavior of the US Patent and Trademark Office, whose idiotic willingness to grant patents on anything without regard for prior art or the obviousness test has totally poisoned the waters of this discussion. The result, as I’ve argued before, is that the net effect of the software-patent system is to serve as a parasitic tax by lawyers on businesspeople. Where I disagree with Jonathan is on what’s known as “business-method” patents: one-click ordering, per-employee pricing. I’m having trouble seeing the benefit to society in granting patents on something that could never possibly be done secretly. I also think that to get a patent, an invention should include innovation both in conception and implementation. The emphasis in the last sentence quoted above is mine. I’ve quoted extensively here from Bray because, having re-read his patent-related essays, I find myself in nearly complete agreement with him. I’m not opposed to idea of the patent system on general principal (as Stallman, and many others, are). And I think in many fields, the system has and continues to work well. But for software the system, in practice, is undeniably broken. There’s an argument to be made that software is inherently different than other field of invention, different in such a way that patents should not apply — or, should apply for a significantly shorter period of time before expiring. You can’t (or at least shouldn’t) be able to patent mathematics, and there are good arguments that programming is a branch of mathematics. But because software patents are granted, concede at least for the moment that certain kinds of software innovations ought to be patentable. Even with that in mind, clearly the U.S. Patent Office is and has granted patents for things which ought not be patentable. Not just silly frivolous things, but patents that have been granted for concepts alone, rather than specific innovative implementations of said concepts. Ideas in the abstract, rather than implementations of ideas. Paul Graham, who has also been awarded software patents, has written well on the subject, too: We, as hackers, know the USPTO is letting people patent the knives and forks of our world. The problem is, the USPTO are not hackers. They’re probably good at judging new inventions for casting steel or grinding lenses, but they don’t understand software yet. And: There’s nothing special about physical embodiments of control systems that should make them patentable, and the software equivalent not. Unfortunately, patent law is inconsistent on this point. Patent law in most countries says that algorithms aren’t patentable. This rule is left over from a time when “algorithm” meant something like the Sieve of Eratosthenes. In 1800, people could not see as readily as we can that a great many patents on mechanical objects were really patents on the algorithms they embodied. Patent lawyers still have to pretend that’s what they’re doing when they patent algorithms. You must not use the word “algorithm” in the title of a patent application, just as you must not use the word “essays” in the title of a book. If you want to patent an algorithm, you have to frame it as a computer system executing that algorithm. Then it’s mechanical; phew. The default euphemism for algorithm is “system and method.” Try a patent search for that phrase and see how many results you get. These arcane rules lead to patents being described in an obfuscated manner. That they are patenting algorithms but must pretend they’re patenting something else is the definition of a broken system. To me, “user interface” patents are hand-in-hand with “business method patents” as examples of things which, no matter how innovative or original, ought not be patentable. They’re idea patents. Adobe, to take one example, has a patent on tabbed palettes. If you’ve used Adobe apps like Photoshop, InDesign, or Illustrator in the past decade, you know what they are. Design applications have been using floating on-screen palettes all the way back to the original MacPaint in 1984. Unlike dialog boxes, they weren’t modal and “floated” over the document window. Unlike menus, they remained visible. They’re ubiquitous in design apps. One shortcoming, however, was that if you opened too many of them, you cluttered your screen — the more palettes you have open, the less room you have for displaying the document itself. Adobe came up with a great feature: they allowed you to dock multiple palettes together as tabs within a single palette window, and you could drag individual tabs between windows or drag them out into their own window. (Similar, at the palette level, to tabbed web browser windows.) Adobe patented the idea, and when Macromedia implemented a version of it, Adobe sued (and won — a measly $2.8 million). To me, that’s exactly the sort of patent litigation that is aimed at stifling innovation rather than rewarding it. Building on the ideas of others is fundamental to competition. No one company can or should be expected to change the entire U.S. patent system. Like any entrenched system with powerful entities who seek to maintain the status quo, we’re likely stuck with it. And so the way the computer industry has dealt with it is detente. Companies obtain as many patents as they can, written as broadly as they can get away with. And since everyone (where by “everyone” I mean all large tech corporations) has a large patent portfolio, and nearly every idea under the sun has been patented by someone to some degree, most of them are inert. Company A doesn’t sue Company B for infringing upon patents held by A because A’s own products almost certainly infringe upon some patents held by B. This why pure patent troll companies such as Nathan Myhrvold’s Intellectual Ventures are so despised. They’re immune from the threat of counter-suit because they have no products or services. Their only business is extorting patent licensing fees. The analogy to nuclear weapons is overwrought when considered literally, but in terms of strategy it’s quite apt. Paul Graham, on Amazon’s notorious “one-click” patent: Where Amazon went over to the dark side was not in applying for the patent, but in enforcing it. A lot of companies (Microsoft, for example) have been granted large numbers of preposterously over-broad patents, but they keep them mainly for defensive purposes. Like nuclear weapons, the main role of big companies’ patent portfolios is to threaten anyone who attacks them with a counter-suit. Amazon’s suit against Barnes & Noble was thus the equivalent of a nuclear first strike. That suit probably hurt Amazon more than it helped them. Barnes & Noble was a lame site; Amazon would have crushed them anyway. To attack a rival they could have ignored, Amazon put a lasting black mark on their own reputation. Even now I think if you asked hackers to free-associate about Amazon, the one-click patent would turn up in the first ten topics. Which brings us to Apple and HTC. Regardless of the merits of all 20 of the patents Apple accuses HTC of violating, strategy-wise the comparison to Amazon and Barnes and Noble seems apt: Apple has the clearly superior product and is winning handily in the marketplace. Whatever benefit in the market Apple hopes to achieve by this suit to me seems likely to be worth far less than the loss of good will and prestige Apple will suffer if they vigorously pursue this case (let alone if they initiate more such suits). Wil Shipley, in an open letter to Steve Jobs regarding the HTC litigation: You’ve famously taken and built on ideas from your competitors, as have I, as we should, as great artists do. Why is what HTC has done worse? Whether an idea was patented doesn’t change the morality of copying it, it only changes the ability to sue. […] If Apple becomes a company that uses its might to quash competition instead of using its brains, it’s going to find the brainiest people will slowly stop working there. You know this, you watched it happen at Microsoft. Copying ideas is how progress is made. It’s copying implementations that is wrong (and illegal). Admittedly there are gray areas, and reasonable people can disagree about whether some specific instances cross that line. But HTC’s phones are not copies of the iPhone. The Nexus One is without question highly influenced by the iPhone, both in terms of physical form factor and the Android software from Google. But it is also without question not a clone. My favorite theory thus far regarding why Apple is suing HTC is expressed entirely in this tweet from John Siracusa: To me, the Apple patent suit smells like nothing more than a manifestation of Jobs’s own sense of injustice. I.e., Jobs is offended by HTC’s products, not worried about them. I can understand the indignation, or at least imagine that I can. Apple’s press releases tend to be remarkably terse and plainspoken, at least by the standards of modern corporate communication. And when Jobs is quoted in them, the words are carefully chosen and meaningful, worthy of being carefully parsed1 — not at all like the bromides attributed to CEOs from most companies in most PRs. The PR announcing these suits against HTC is no exception: “We can sit by and watch competitors steal our patented inventions, or we can do something about it. We’ve decided to do something about it,” said Steve Jobs, Apple’s CEO. “We think competition is healthy, but competitors should create their own original technology, not steal ours.” That’s not the language of a licensing dispute or the beginning of a polite negotiation. That’s the language of a man aggrieved. During Jobs’s iPhone introduction keynote address in January 2007, before showing what the iPhone looked like, Jobs put up this slide showing four of the then-leading smartphones on the market: the Motorola Q, a BlackBerry, a Palm Treo, and the Nokia E62. Those pre-iPhone smartphones Jobs displayed all shared the same fundamental design: half-screen, half keyboard, and an up/down/left/right navigation controller. Now look at this prototype Android phone Gizmodo spotted in December 2007 — 11 months after the iPhone introduction. Android was conceived of that same old model — the prototype Gizmodo found in December 2007 would have fit perfectly alongside the other four phones in Jobs’s keynote slide. The gaping chasm between that Treo-ish/BlackBerry-ish prototype Android device and the HTC G1 that went on sale a year later (let alone the Nexus One today) was bridged by ideas from the iPhone. The iPhone introduced a new model. A true great leap forward in the state of the art. Not a small screen that shows you things which you manipulate indirectly using buttons and trackballs occupying half the device’s surface area, but instead a touchscreen that occupies almost the entirety of the surface area, showing things you manipulate directly. Android is a far better platform today than it would have been if Apple had never created the iPhone. That, in some sense, is not fair. I think Siracusa is exactly right that Jobs has a particularly acute sensitivity to this sort of unfairness. This litigation, perhaps then, isn’t about particular specific patented components, but rather is about the big idea, the general gist and grand ambition of the iPhone as the basic model for how modern mobile devices should be designed and work. No doubt some of you are nodding your heads and see this as justification for Apple’s suit. But life isn’t fair. Great ideas make the world better. Apple can rightly expect to benefit greatly from the ideas embodied by the iPhone, but they can’t expect to reap all of the benefits from those ideas. That’s the nature of implementing insanely great ideas. The bar has been raised, and, yes, Apple did most of the lifting. That’s how it goes. Paul Graham, yesterday: If this had happened a day earlier I don’t think I would have posted that RFS. Apple is inching ever closer to evil, and I worry that there’s no one within the company who can stand up to Jobs and tell him so. “That RFS” is the request for iPad software startups from Graham’s Y Combinator, and lest you think “evil” is too overwrought a word, Graham clarified later in the same thread: Historically the word “evil” has had a pretty broad meaning. Among tech companies the word has a new and fairly specific sense that follows from Paul Buchheit’s slogan “Don’t be evil.” That’s the sense I was using. It has a pretty low bar. It means, roughly, winning by taking advantage of people instead of by doing good work. I wouldn’t use the word evil this way, but I’m right there with Graham on this sentiment. And I say this not in any sort of hippy-dippy sense of expecting or even hoping for Apple to behave selflessly, holding them to a separate idealistic standard, or expecting them to fight with one arm tied behind their corporate back. And only a fool would argue that a company should never seek redress through litigation. But I believe that it’s good business, in the long run, for a company’s acts of aggression to take place in the market, not in the courts. My concern regarding this litigation against HTC is that it looks like an act of competitive aggression, not defense. I can think of only a few optimistic angles for this suit. One is that perhaps it’s a by-product of the suit Apple is engaged in against (and initiated by) Nokia. Apple’s counter-suit against Nokia involves some of the same patents at play here, and perhaps Apple’s lawyers have concluded that they need to enforce them against someone like HTC in order to use them in their counter-suit against Nokia. Or, perhaps one or more of the truly technical patents Apple has cited against HTC are genuine instances of intellectual property theft, the specific nature of which is unclear from the opaque language of the patent filings, and the rest of the cited patent violations were tacked on as part of a legal strategy along the lines of “If you’re going to punch them, punch them as hard as you can”. I.e. that they’ve filed suit as widely as they can, but have specific narrow violations in mind. What worries me is that idea that Apple, or even just Steve Jobs, believes that phones like the Nexus One have no right to exist, period, and that patent litigation to keep them off the market is in the company’s interests. I say it’s worrisome not because I think it’s evil, or foolish, or unreasonable, but because it is unwise, shortsighted, and unnecessary. For example, consider the timing of this PR Apple released early in the morning on January 5, announcing the three-billionth download from the App Store. Jobs is quoted thus: “The revolutionary App Store offers iPhone and iPod touch users an experience unlike anything else available on other mobile devices, and we see no signs of the competition catching up anytime soon.” January 5 was the day Google held its event to unveil the Nexus One.↩
-
★ Let the Tea Leaf Reading Begin
The best thing about being an Apple observer is that even when the company does make a long-awaited announcement, it inevitably leads to new questions regarding what exactly they mean. Apple punditry is the Kremlinology of the tech world. So it is with this week’s announcement from Steve Jobs1 that, yes, “We want native third party applications on the iPhone, and we plan to have an SDK in developers’ hands in February.” We now know two new things: (1) that there will be “native third party applications on the iPhone”; and (2) that the SDK is scheduled for February. That leaves a long list of questions. Whither Widgets? For one: What exactly is a “native third party application”? The obvious answer is the sort of UIKit-based Cocoa-ish applications that underground iPhone hackers have been creating over the last two months — the exact sort of native apps that Apple has itself already written for the iPhone and iPod Touch. For all we know at this point, though, it could be something more like Dashboard widgets — but I think that’s unlikely. Jobs wrote: > With our revolutionary multi-touch interface, powerful > hardware and advanced software architecture, we believe we > have created the best mobile platform ever for developers. JavaScript, HTML, and CSS are cool in that they’re widely-used, widely-known coding standards — but they’re not a good way to create user experiences that take full advantage of the iPhone, and would be pretty hard for Apple to pass off as an SDK for “native apps”. Third party developers want access to the same dog food Apple’s own iPhone engineers are eating. Plus, there’s the issue of performance. Iconfactory developer Craig Hockenberry, who has been tinkering with the unofficial iPhone developer tools to create an iPhone-native version of Twitterrific, wrote a splendid weblog entry titled “Benchmarking in Your Pants” regarding the lackluster performance of JavaScript code running in MobileSafari compared to compiled Objective-C code running in a native iPhone app. Function calls, for example, were 226 times slower in JavaScript. (Hockenberry also benchmarked JavaScript running on the iPhone compared to the same code running in Safari on an Intel-based iMac; the code ran about 80 times faster on the iMac.) Back in January at the iPhone’s introduction in the Macworld Expo keynote, Jobs described some of the apps on the iPhone, including Weather and Stocks, as “widgets”. My somewhat-informed understanding is that Apple’s original plan was for the iPhone to ship with its major apps written in Cocoa and with a handful of smaller apps written as Dashboard-style HTML/CSS/JavaScript widgets — but that this plan was scuttled for performance reasons, and the Weather and Stocks widgets2 were rewritten as UIKit Objective-C apps sometime this spring.3 My guess is that they ran into what Hockenberry documented: JavaScript on the current iPhone just isn’t fast enough to provide an iPhone-caliber user experience. So my money is that the iPhone SDK that Apple plans to release this winter is the real thing — Cocoa-style UIKit apps written in Objective-C. Security? Jobs wrote: It will take until February to release an SDK because we’re trying to do two diametrically opposed things at once—provide an advanced and open platform to developers while at the same time protect iPhone users from viruses, malware, privacy attacks, etc. This is no easy task. Some claim that viruses and malware are not a problem on mobile phones—this is simply not true. There have been serious viruses on other mobile phones already, including some that silently spread from phone to phone over the cell network. As our phones become more powerful, these malicious programs will become more dangerous. And since the iPhone is the most advanced phone ever, it will be a highly visible target. External security — the threat of vulnerabilities that would allow malfeasants to compromise a victim’s iPhone — is a serious matter. There have already been several published exploits against the iPhone, including an as-of-this-writing open vulnerability in TIFF-processing code in the current iPhone OS. So clearly there is some merit to Jobs’s stated security concerns. As it stands in the current iPhone OS, all processes run as the root user; in broad layman’s terms, any process has access to everything else on the phone. So when a buffer overflow can be exploited to allow remote code execution, that code can do anything. To allow third-party iPhone apps to run today would be to trust those third-party developers not to write code with any security flaws. What the iPhone needs before Apple will allow third-party apps to run is some sort of sandbox, a way to prevent application processes from being able to access things they shouldn’t be allowed to access. But iPhone Cocoa apps are no more inherently susceptible to buffer overflow vulnerabilities than Mac Cocoa apps. And the hysteria over the iPhone’s current “everything runs as root” situation is overblown.4 Applications on your Mac don’t run as the root; they run under your user account. But all of your data — your email, your address book, your documents, everything your apps can read or write without administrator authentication — is vulnerable to any sort of hypothetical buffer overflow exploit on the Mac, and would be on the iPhone, too, even if iPhone apps didn’t all run as root. Sure, root privileges allow an exploit to do anything, but the most important thing on your system is your personal data, and an exploit doesn’t need root privileges to access that. I’m thinking Apple is more concerned about internal security — about having third-party apps limited to a sandbox so that user-installed code has no access to things like, say, the phone network modem’s firmware (the component that you need to diddle with to create SIM unlocks). That’s the key difference between the iPhone and the Mac, security-wise. Which Third-Party Developers? Mac OS X is pretty much completely open to development; even the developer tools are free, and anyone is free to write whatever software they want for the Mac. It seems unlikely that iPhone OS X development is going to be like that. One possibility is that the iPhone SDK will only be available to developers with ADC Select ($499) or Premiere ($3,499) accounts. (Premier and Select ADC members are the only ones with access to pre-release Mac OS X seeds, for example.) If that’s the case, it’s not going to be popular with hobbyist developers, but most professional Mac developers already have paid ADC memberships, and, let’s face it, we all know most iPhone apps are going to be written by Mac developers. Interviewed via email, Craig Hockenberry told me, “If there’s a simple way to get third party apps on the iPhone, you keep 90 percent of the developers happy and jailbreak/unlock has much less momentum. Sure, there will still be people that want to ‘buck the system’ but they’ll be in the minority rather than the majority.” The most intriguing part of Jobs’s announcement was this section, regarding security: Some companies are already taking action. Nokia, for example, is not allowing any applications to be loaded onto some of their newest phones unless they have a digital signature that can be traced back to a known developer. While this makes such a phone less than “totally open,? we believe it is a step in the right direction. We are working on an advanced system which will offer developers broad access to natively program the iPhone’s amazing software platform while at the same time protecting users from malicious programs. It’s hard not to interpret the scare quotes around “totally open” as a reference to Nokia’s recent “Open to Anything” ad campaign — sort of a you guys aren’t completely open either call-out. This seems like a pretty clear indication that Apple is working on a similar signing system for iPhone apps. Restricting development to paid ADC members would instantly allow Apple to associate app signatures “back to a known developer”. Here’s more information from Nokia on the signing program Jobs mentioned; here’s similar information on the Symbian site. Which Apps? Another question is whether Apple is going to allow participating (trusted-by-Apple) developers to write whatever apps they want, signing the apps themselves, or if apps will need to be approved case-by-case by Apple before being signed. Mac OS X Leopard includes a new “application signing” feature, described by Apple thusly: A digital signature on an application verifies its identity and ensures its integrity. All applications shipped with Leopard are signed by Apple, and third-party software developers can also sign their applications. That same page describes a “sandboxing” feature that seems applicable to the iPhone, too: Sandboxing prevents hackers from hijacking applications to run their own code by making sure applications only do what they’re intended to do. It restricts an application’s file access, network access, and ability to launch other applications.” The prototypical example of a potentially popular app that Apple might refuse to approve would be a VOIP app like, say, Skype, in that it would undermine the need for the phone network, which in turn undermines Apple’s revenue sharing with the iPhone’s exclusive network partners. Or, say, instant messaging, the omission of which from the current iPhone is seen by many as a concession to the fact that heavy SMS users pay handsomely for extra monthly messages. (Personally, I suspect iChat for iPhone simply didn’t make the cut for 1.0 but is planned for a future update.) “Nokia’s model is to run as trusted/untrusted,” said Hockenberry. “Trusted apps get to access more than untrusted ones. This model could be extended to allow different levels of access based upon whatever Apple wants (as owner of the root certificate.) Basic access for Wi-Fi, extended access for EDGE, hardware access for deep pockets, etc.” That makes sense, and strikes me as a likely course for Apple. Development There’s a question, then, of how developers will write the apps in the first place. If iPhones only run third-party apps that have been approved by Apple, how do you develop an application in the first place before it’s been approved? Steven Frank — who, as co-founder of Panic and an unrepentant gadget hound, may well be the single most interested person in the world in a supported iPhone SDK — described to me via email the development process for the Danger Hiptop/Sidekick: “The Hiptop/Sidekick platform has a Java SDK that abstracts away all the low-level hardware stuff so you can’t touch it, while still providing everything you need to write an application. You test and debug in an emulator/virtual machine that can simulate edge conditions like loss of cellular network availability and so on. When you’re almost done, and ready to try on real hardware, you apply for a ‘developer key’, which is a small certificate that you install on the phone that enables you to run third-party apps that didn’t come from the on-device for-purchase catalog. To get the developer key, you have to prove to them you actually have an almost complete app, and aren’t just some kid who wants hot Yung Joc ringtones by submitting a build of your application. You also have to sign a waiver that says you are no longer eligible for support from your cellular carrier.” The iTunes App Store? Which leaves us with the question of distribution and installation. The obvious route is the same one Apple has taken with iPod games: the iTunes Store. Apple, in this case, would likely get a cut of every sale. From a user’s perspective, it’d be easy and obvious: shop and pay for apps in iTunes, and iTunes takes care of installing the software, and, perhaps, synching data. This is similar to the Danger model — where apps must be approved, and can be sold only through the official channel. Limiting, to be sure, but as Frank put it, “The process [of developing for Danger] is somewhat tedious, but still an order of magnitude better than not allowing third-party applications, period.” Frank also pointed out the most glaring downside of Danger’s pay-to-play development model: “One drawback to this approach from the user’s perspective is that there is basically no free third-party software. Everything costs at least a couple bucks.” The announcement appeared on Apple’s Hot News web page, but with no permalink, so it’s likely to disappear from Apple’s web site in a week or two as newer items appear. I’ve saved a plain text copy here for posterity.↩ I wonder if the Calculator app was originally a widget, too. UI-wise, it’d certainly be a cinch, because just like with the iPhone’s Weather and Stocks apps, it more or less looks and acts exactly like the corresponding widget in Mac OS X. So my theory is that when Apple made the decision to rewrite the iPhone widgets as native iPhone Cocoa apps, they used the widgets as the specs for the apps. “Make a native app that looks and acts exactly like this widget,” more or less. One thing that makes me think this is that the iPhone Calculator app doesn’t make any sounds when you press the buttons. Pure JavaScript/HTML widgets can’t make sounds when you click or tap buttons. I find typing on the iPhone keyboard to be much more satisfying with the sound on; with the sound off, because the keys are virtual, there’s no sensory feedback at all. The Calculator app would feel more real if it simply made the same button-clicking noises as the iPhone keyboard.↩ That this change was — I believe — made rather late in the game might explain why vestigial references to “widgets” remained in the shipping iPhone 1.0 software. (It could also mean, of course, that Apple plans to re-expose this feature at some point in the future.)↩ It certainly is a curious question why all iPhone apps run as root. I don’t know the answer. But I’ll bet there’s an interesting engineering trade-off involved somewhere. If you think the reason is laziness or ignorance on the part of the iPhone OS X engineers, you’re an idiot.↩
-
★ The Tablet
Another former Apple executive who was there at the time said the tablets kept getting shelved at Apple because Mr. Jobs, whose incisive critiques are often memorable, asked, in essence, what they were good for besides surfing the Web in the bathroom. —”Just a Touch Away, the Elusive Tablet PC”, The New York Times, 4 October 2009 Here’s the thimbleful of information I have heard regarding The Tablet (none of which has changed in six months): The Tablet project is real, it has you-know-who’s considerable undivided attention, and everyone working on it has dropped off the map. I don’t know anyone who works at Apple who doubts these things; nor do I know anyone at Apple who knows a whit more. I don’t know anyone who’s seen the hardware or the software, nor even anyone who knows someone else who has seen the hardware or software. The cone of silence surrounding the project is, so far as I can tell, complete.1 The situation is uncannily similar to the run-up preceding the debut of the original iPhone in January 2007, including many of the same engineers and software teams at Apple — such as those who built the iPhone Mail, Calendar, and Safari apps — disappearing into a black hole. The iPhone remained a secret until Steve Jobs took it out of his jeans pocket on stage at Macworld Expo. All of which is to say that what follows is my conjecture. Pure punditry, not one of those smarmy “predictions” where I know full well in advance what’s going to happen. I have a thousand questions about The Tablet’s design. What size is it? There’s a big difference between, say, 7- and 10-inch displays. How do you type on it? With all your fingers, like a laptop keyboard? Or like an iPhone, with only your thumbs? If you’re supposed to watch video on it, how do you prop it up? Holding it in your hands? Flat on a table seems like the wrong angle entirely; but a fold-out “arm” to prop it up, à la a picture frame, seems clumsy and inelegant. If it’s just a touchscreen tablet, how do you protect the screen while carrying it around? If it folds up somehow, how is it not just a laptop — why not put a hardware keyboard on the part that folds up to cover the display? (Everyone I know at Apple refers to it as “The Tablet”, but so far as I can tell, that’s because that’s what everyone calls it, not because anyone knows that it actually even is, physically, a tablet. And “The Tablet” most certainly is not the product name.) If it’s too big to fit in a pants pocket, how are you supposed to carry it around? And but if it does fit in a pants pocket, how is it bigger enough than an iPod Touch to justify existing? And so on. But there’s one question at the top of the list, the answer to which is the key to answering every other question. That question is this: If you already have an iPhone and a MacBook; why would you want this? The epigraph I used to start this piece — the bit about Steve Jobs demanding that a tablet be useful for more than just reading on the can — indicates that Apple will release nothing without such an answer. I agree that such an answer is essential. Successful new gadgets always seem to occupy a clearly defined place alongside, or replacing, existing devices. The Flip filled a previously empty niche for a small, cheap, simple video camera. How was the iPod better than existing portable music players? It fit 1,000 songs in your pocket, with a fun interface that let you find them easily. Why buy an iPhone to replace your existing mobile phone? Because there was a clear need for a modern handheld general-purpose computer. But how much room is there between an iPhone (or iPod Touch) and a MacBook (or other laptop computer, running Windows or Linux or whatever)? What’s the argument for owning all three? “I’d use it on the couch and lying in bed” is not a good answer. You can already use your iPhone or MacBook on the couch and in bed. It strikes me as foolish to market a multi-hundred-dollar device that people are expected to leave on their coffee table. “It’s a Kindle killer” is not a good answer. If you think Apple is making a dedicated device for reading e-books and articles, you’re thinking too small. As profoundly reticent as Steve Jobs is regarding future Apple products, when he does speak, he’s often surprisingly revealing. David Pogue asked him about the Kindle a few months ago: A couple of years ago, pre-Kindle, Mr. Jobs expressed his doubts that e-readers were ready for prime time. So today, I asked if his opinions have changed. “I’m sure there will always be dedicated devices, and they may have a few advantages in doing just one thing,” he said. “But I think the general-purpose devices will win the day. Because I think people just probably aren’t willing to pay for a dedicated device.” He said that Apple doesn’t see e-books as a big market at this point, and pointed out that Amazon.com, for example, doesn’t ever say how many Kindles it sells. “Usually, if they sell a lot of something, you want to tell everybody.” Of course, this is the same Steve Jobs who back in January 2008 told The New York Times’s John Markoff: “It doesn’t matter how good or bad the product is, the fact is that people don’t read anymore,” he said. “Forty percent of the people in the U.S. read one book or less last year. The whole conception is flawed at the top because people don’t read anymore.” One could reasonably argue that the “people don’t read” comment, taken at face value, suggests that Apple has no interest in that market, period. I, however, would square the two remarks as follows: Not enough people read to make it worth creating a dedicated device that is to reading what the original iPod was to music. (Everyone, for practical definitions of “everyone”, listens to music.) But e-reading as one aspect among several for a general-purpose computing device — well, that’s something else entirely. The pre-Touch iPod was (and remains) an enormous success. It changed the music industry and rejuvenated Apple. But it was and remains a dedicated device; originally focused on audio, now capable of the sibling feature of video. The iPhone, on the other hand, was conceived and has flourished as a general-purpose handheld computing platform. It was not introduced as such publicly, and is not pitched as such in Apple’s marketing, but clearly that’s what it is. The iPhone was described by Jobs in his on-stage introduction as three devices in one: “a widescreen iPod with touch controls, a revolutionary mobile phone, a breakthrough Internet communicator”. Thus, it was clear what people would want to do with it: watch videos, listen to music, make phone calls, surf the web, do email. The way Apple made one device that did a credible job of all these widely-varying features was by making it a general-purpose computer with minimal specificity in the hardware and maximal specificity in the software. And, now, through the App Store and third-party developers, it does much more: serving as everything from a game player to a medical device. Do I think The Tablet is an e-reader? A video player? A web browser? A document viewer? It’s not a matter of or but rather and. I say it is all of these things. It’s a computer. And so in answer to my central question, regarding why buy The Tablet if you already have an iPhone and a MacBook, my best guess is that ultimately, The Tablet is something you’ll buy instead of a MacBook. I say they’re swinging big — redefining the experience of personal computing. It will not be pitched as such by Apple. It will be defined by three or four of its built-in primary apps. But long-term, big-picture? It will be to the MacBook what the Macintosh was to the Apple II. I am not predicting that Apple is phasing out the Mac. (On the contrary, I’ve heard that Mac OS X 10.7 is on pace for a developer release at WWDC in June.) Like all Apple products, The Tablet will do less than we expect but the things it does do, it will do insanely well. It will offer a fraction of the functionality of a MacBook — but that fraction will be way more fun. The same Asperger-y critics who dismissed the iPhone will focus on all that The Tablet doesn’t do and declare that this time, Apple really has fucked up but good. The rest of us will get in line to buy one. The Mac is, and will remain, Apple’s answer to what you use to do everything. The Tablet, I say, is going to be Apple’s new answer to what you use for personal portable general computing. Put another way, let’s say instead of a MacBook and an iPhone, you’ve got an iMac and an iPhone, but you also want a portable secondary computer. Today, that portable from Apple (portable as opposed to the iPhone’s mobile) is a MacBook. With The Tablet, you’ll have the option of a device that will more closely resemble the iPhone than the iMac in terms of concept and the degree of technical abstraction. The Tablet OS The original 1984 Mac didn’t abstract away the computer — it made the computer itself elegant, simple, and understandable. Very, very little was hidden from the typical user. Mac OS X is vastly more complex technically and conceptually, as it must be due to the vastly increased complexity and capability of today’s hardware. But Mac OS X has always tried to have it both ways: a veneer of simplicity that doesn’t cover the entire surface of the system. The user-exposed file system is a prime example. On the 1984 Mac, the entire file system was exposed, but the entire file system fit on a 400 KB floppy disk. On Mac OS X, the /System/Library/ folder, one of many exposed fiddly sections of the file system browsable in the Finder, contains over 90,000 items, not one of which a typical user should ever need to see or touch. The iPhone OS offers a complete computing abstraction. Under the hood, it’s just as complex as Mac OS X. On the surface, though, it is even more simple and elegant than the original Mac. No technical complexity is exposed. Hierarchy is minimized. It relegates the file system to a developer-level technology rather than a user-level technology. (Did you know the file system on iPhones is case sensitive?) But so while I think The Tablet’s OS will be like the iPhone OS, I don’t think it will be the iPhone OS. Carved from the same OS X core, yes, but with a new bespoke UI designed to be just right for The Tablet’s form factor, whatever that form factor will be. One common prediction I disagree with is that The Tablet will simply be more or less an iPod Touch with a much bigger display. But in the same way that it made no sense for Apple to design the iPhone OS to run Mac software, it makes little sense for a device with a 7-inch (let alone larger) display to run software designed for a 3.5-inch display. The iPhone OS user interface was not designed in the abstract. It’s entirely about real-world usability, and very much designed specifically around the physical size of the device itself. The size and spacing of tappable targets are designed with the size of human thumb- and fingertips in mind. More importantly, the whole thing is designed so that it can be used one-handed. Even an adult with relatively small hands can go from one corner to the other with their thumb, holding the iPhone in one hand. Mac OS X apps couldn’t run on an iPhone display because they simply wouldn’t fit, and the parts that did fit would contain buttons and other UI elements that were far too small to be used. Running iPhone software on a much larger display presents the opposite problem: it’s not that the UI couldn’t be scaled to fill the screen, it’s that it would be a waste to do so. A 7-inch display isn’t twice the size of an iPhone’s, it’s four times bigger in surface area. I’m not sure even Shaquille O’Neal could hold a 7-inch iPod Touch in one hand and swipe from corner to corner with his thumb. Why would Apple stretch a UI designed to afford for one-handed use on 3.5-inch displays to cover a 7-inch (or larger) display that couldn’t possibly be used one-handed? If Apple’s starting with a hardware size where the iPhone OS can’t be used one-handed, then trust me, they’re designing a new interaction model. Apple is not in the business of making monolithic OSes that they cram down your throat on as many widely-varying devices as possible. Apple is in the business of making complete products, for which they craft derivative OSes to fit each product. There is a shared core OS. There is not a shared core UI.2 If you’re thinking The Tablet is just a big iPhone, or just Apple’s take on the e-reader, or just a media player, or just anything, I say you’re thinking too small — the equivalent of thinking that the iPhone was going to be just a click wheel iPod that made phone calls. I think The Tablet is nothing short of Apple’s reconception of personal computing. “Make no little plans. They have no magic to stir men’s blood and probably themselves will not be realized. Make big plans; aim high in hope and work, remembering that a noble, logical diagram once recorded will never die, but long after we are gone will be a living thing, asserting itself with ever-growing insistency. Remember that our sons and grandsons are going to do things that would stagger us. Let your watchword be order and your beacon beauty. Think big.” —Daniel Burnham, Chicago architect. (1864-1912) The only known breakage of the cone of silence around Apple’s tablet project I’m aware of are the meetings Apple has held with publishing industry executives. The way these meetings work, from what I’ve gathered, is as follows. Apple brings no hardware. They bring no software. They show no mockups. They do not even completely acknowledge that they’re making a new device. The people from Apple simply say something along the lines of, “If we were to create a new platform for book/magazine/newspaper content, would you be interested in offering your content for it?” Apple is, without any question in my mind, courting book and periodical publishers. But that doesn’t mean Apple trusts any of them enough to reveal or describe in detail what it is they’re actually working on.↩ That said, I would not be surprised to find out that The Tablet uses UIKit, a.k.a. Cocoa Touch, as its programming API. I don’t think the same apps will run as-is on both OSes, but I do think you might use the same set of APIs to write apps for both platforms. (Or, perhaps iPhone apps could run as less-than-full-screen widgets on the larger tablet display.)↩
-
★ Palm Saturday
The iPhone was introduced at Macworld Expo on 9 January 2007. On that day, Palm Inc. was screwed. Their relevance in the industry had already been slowly draining, and they not only had no available products in the same league as the iPhone, they had no future products in the same league. For all the mistakes Palm made to get to that point, and they clearly made many, it’s quite possible that they have done everything right since then. They abandoned whatever then passed for their product plan. They hired Jon Rubinstein and gave him control over building a new hardware and software engineering division. They hired not just new engineers, but great designers and all sorts of other smart and talented people essential to building a world-class engineering, design, and developer culture. In short, they did something few companies, no matter how deeply in trouble, ever do: they recognized that they were screwed and took drastic action. It’s an overused phrase, but in this case it is true: they’ve bet the company. Palm designed, built, and released the Pre, WebOS, and an app store, all in about two years. I’ve not yet seen or used an actual Pre, but I have been using the WebOS, emulated on my Mac, as a member of Palm’s beta SDK program, and it is excellent. It is hard to imagine how Palm could have produced anything better in the same amount of time. The question is whether even the best they could do is still too little, too late. Even if, for the sake of argument, we concede that Palm has caught up to the iPhone technically, Apple has a two year marketing head start, too. The iPhone has already joined the iPod as not just a tech culture hit, but a pop culture hit. Everyone knows what an iPhone is. It also has worldwide distribution; the Pre is exactly where the iPhone was two years ago: on one carrier, only in the U.S. The iPhone’s popularity has led to third-party developer support, and third-party developer support has in turn made the iPhone even more popular. It’s a virtuous circle. That sweaty “Developers, developers, developers, developers” rant is probably the smartest thing Steve Ballmer has ever said. But so what does the Pre have that the iPhone lacks? The two biggest differences are its hardware keyboard and that it has a different exclusive U.S. carrier, Sprint. But Sprint is smaller than AT&T. Imagine instead if the Pre were launching tomorrow morning on Verizon. That might have proved to be an interesting advantage against the iPhone. That leaves the keyboard. I’ve been thinking about this ever since the keyboard-less iPhone launched, and it is my theory that a hardware keyboard is a significant selling point for only one group of customers: those who already own a phone with a hardware keyboard, and that group is a niche. A nice niche, but a niche nonetheless. Here’s why. Most normal people have yet to buy their first smartphone. That’s why the stakes are so high — it’s a wide open market frontier, but it won’t remain that way for long. Normal people aren’t planning to do much typing on their new smartphone, and they’re probably right. Any smartphone QWERTY keyboard, software or hardware, is going to be better than what most people are used to, which is pecking things out on a phone with a 0-9 numeric keypad. I type far better on my iPhone than I expected I’d be able to, and that seems to be true for everyone I know who owns one. The only people who struggle with the iPhone keyboard are those who are already accustomed to a hardware smartphone keyboard. It is definitely different. Here’s what Dieter Bohn of PreCentral wrote in his Pre review: I’ve been using QWERTY keyboards on phones for over seven years now and I had no problem adjusting to the Palm Pre. If you’re looking for a comparison, I’ll say that it’s not as good as your standard BlackBerry keyboard, but for 90% of people it’s going to be much better than the iPhone’s on-screen software keyboard. My take is that his seven years of harware keyboard use have warped his perspective. He’s got it backwards: for 90 percent of people, it doesn’t make a difference whether the keyboard is hardware of software. So while the comparisons between the Pre and iPhone are obvious and inevitable, I think the Pre stands a much stronger chance of stealing customers away from RIM than from Apple. For as good as the Pre is, and I’m convinced it is excellent, it just doesn’t have much to offer that would sway someone considering an iPhone. But for someone considering a BlackBerry, the Pre might look very sweet: a big bright screen, a beautiful modern user interface design, a kick-ass mobile web browser, and, yes, a hardware keyboard. The Pre is the BlackBerry Bold done right. Another aspect where the Pre is different than the iPhone is in nerd appeal. Here’s a passage from Jason Chen’s Pre review for Gizmodo: Opening multiple apps at once really does slow down the phone enough to be noticeable. In fact, if you’re doing something particularly intensive, you’ll actually notice your music stutter, which we’ve never experienced once on the iPhone. Ever. The problem with giving you the ability to open a lot of apps at once means you need to police yourself and close them when they’re not in use. But it’s damn well worth it. Being able to view a PDF, then flipping over to Messaging answer a text, then over to Music to change a song, then over to email to tap out a quickie—that’s computing. What’s fascinating about this passage is that Chen clearly intends for it to be taken as a compliment — he is praising the Pre’s multitasking support and interface. But these exact words also summarize perfectly why Apple has withheld multitasking from third-party iPhone applications. The Pre will let you run too many apps at the same time and suffer the consequences. The iPhone will not. Palm has chosen a different trade-off than Apple in this regard, and it might help them carve out a segment of the market that the iPhone does not, and probably never will, appeal to — the “don’t treat me like a child, let me shoot myself in the foot if I want to, I despise artificial constraints imposed upon me” crowd. Some expert users will see the Pre’s stance as a huge win. Regarding the Mojo SDK and Eating Their Own Dogfood One misconception I’ve seen this week is that the Pre’s “web-based” SDK is similar to the development situation for the iPhone during its first year. This is false, but it’s easy to see the confusion because of all the talk about WebOS apps being written using “HTML, CSS, and JavaScript”. Prior to Apple’s release of the Cocoa Touch APIs and App Store, the developer story for the iPhone was “just write iPhone-optimized web apps”, where by “web apps” they meant “web sites” — something delivered from a remote web server that ran within a page in MobileSafari. Yes, Palm’s Mojo SDK is based on HTML and CSS for layout and JavaScript for programming. But it includes a real API for WebOS-specific things. JavaScript executing in a WebOS app can do many things that JavaScript running in a browser web page cannot. It’s conceptually very similar to Mac OS X’s Dashboard — WebOS apps are like Dashboard widgets, not web pages. They’re installed on the device, not loaded over the web from a server. What was frustrating for would-be iPhone Cocoa developers during the period where Apple was telling them to “just write web apps” was that Apple itself, of course, was writing its own iPhone apps using Objective-C. It just wasn’t (and isn’t) possible to write an iPhone web app that looked or felt anywhere near as nice as a real Cocoa Touch iPhone app. But Mojo, on the other hand, is what Palm is using to write its own WebOS apps. They’re up to their ears in Mojo dogfood. Third-party WebOS apps have the potential to be just as nice as Palm’s WebOS apps, because they’re all written using the Mojo APIs. It’s an open question whether Mojo will prove to be a weakness (because it’s slower than compiled code), strength (because HTML, CSS, and JavaScript are so familiar to so many existing developers), or non-issue. But however this question is resolved, Palm’s own WebOS apps are in the same boat as third-party apps, which is nothing at all like the pre-SDK iPhone situation.
-
★ The iPhone 3G
Pt. 1: Macro Let’s just say it up front: the iPhone is the greatest piece of consumer electronics that has ever been made. If I could travel back 20 years and show my then 15-year-old self just one thing the future of today, it would be the iPhone. It is our flying cars. Star Trek-style wireless long-distance voice communicator. The content of every major newspaper and magazine in the world. An encyclopedia. Video games. TV. Etc. None of these features is quite what an imagination of the ’80s would have predicted. The TV, for example, is far from the imaginary “pocket TV” of my youth, which was rooted in the concept of broadcast TV channels. But it is a TV. In some ways it is worse; you cannot use an iPhone to, say, watch a live broadcast of a sporting event. In many ways, though, it is better; it stores content, including full-length major motion pictures, which you can watch whenever you want. A pocket full of movies was simply unimaginable 20 years ago. And it’s all in one easily pocketed gizmo. Each of these features is of course available in devices other than the iPhone. A checklist of the iPhone’s features is not, in and of itself, impressive. Some competing devices, in fact, offer all the same fundamental features of the iPhone. The difference is in the overall experience. (Even a $10 Nokia dumbphone, combined with today’s worldwide cellular and satellite phone network, can do the Star Trek-wireless voice communicator trick. That alone would be impressive compared to the brick-sized fabulously expensive cellular phones of the ’80s.) Everything Apple as a company has ever stood for, good and bad, was to get to the point where they could make this. It’s a computer you can take with you everywhere, so small you wouldn’t really even want it much smaller, even if it were possible. In software, Apple went back and rethought certain priorities with the iPhone compared to Mac OS X. On Mac OS X, scrolling prioritizes visual fidelity but can be painfully slow. (Not so much with today’s Mac hardware, but in the early days of Mac OS X, scrolling or resizing windows could be molasses slow. iPhone scrolling, on the other hand, is almost always fluid and perfectly responsive, but the content often doesn’t keep up. The checkerboard background in MobileSafari is the most obvious example of this. The illusion that your thumb or finger is actually moving the screen contents is astoundingly effective. Mac OS X values the visual over the feel; iPhone OS is vice versa, and I prefer it. In hardware, the radical reduction of physical buttons has proven to be genius. The iPhone not only eschews a keypad and keyboard, but also those green/red place-call/end-call buttons that you see on nearly every other phone in the world. The iPhone has just four buttons: power, volume up, volume down, and home. That seems just right. I’ve gotten satisfyingly proficient typing with the on-screen touch keyboard. My single biggest gripe is that my right thumb often hits the Return key when I’m trying to hit the space bar. In another five years, one of today’s iPhones will be no more than a sentimental curiosity, painfully slow both in terms of networking and computation. The iPhone has significant and obvious shortcomings. But it is an order of magnitude better than anything that came before it. Pt. 2: Micro I bought my original iPhone on day one. When the iPhone 3G arrived, I figured I could wait. In early August, one month after they went on sale, I upgraded. In a nut, the iPhone 3G is aptly named, in that it isn’t much more than the iPhone plus 3G. If they’d called it “iPhone 3G (and GPS)” the name alone would have completely described what was new, technically at least. The iPhone 3G uses the same CPU and has the same amount of RAM (128 MB) as the original. It is an iteration. If you’ve got an original EDGE iPhone, the only factor that really matters with regard to whether you’d be happy after upgrading is the quality of the 3G service where you live. I, apparently, am lucky. 3G service in center city Philadelphia, the surrounding suburbs, and at the New Jersey shore has been terrific. Even before the 2.1 OS update, I had few complaints about dropped calls, and network speed has far exceeded my expectations. Browsing with 3G on the iPhone generally feels just about as fast as browsing with Wi-Fi — the CPU often seems to be the limiting factor in MobileSafari’s rendering speed, not the network. In addition to the faster data speeds and higher-quality audio, 3G offers one additional advantage over EDGE: 3G can take an incoming phone call while simultaneously using the data network. I missed a surprising number of calls on my old iPhone while dicking around waiting for pages to load in Safari. The main problem I initially ran into with 3G networking was that it would occasionally get stuck. I’d try to load a web page, and the inside-the-location-field progress bar in MobileSafari would simply never get past the “h” in “http:”. In most cases, turning the iPhone completely off and back on would fix this. Even better: I have not seen this problem once since upgrading to the 2.1 OS. Tethering my 3G connection with NetShare — sadly, no-longer-available from the App Store — my MacBook Pro achieves download speeds of 700-900 kb/s, and upload speeds of 200-400 kb/s. Tethering with EDGE, I see download speeds of about 200 kb/s. Thus, for me, networking far exceeds Apple’s marketing claim of “double the speed”, and for that alone the upgrade price and slightly higher monthly plan are well worth it.1 (NetShare is simply remarkable, and deserves a full digression. After just one month of owning an iPhone 3G, the $10 I spent on NetShare is some of the best money I’ve ever spent. The multi-step process required to get it working, which you can only partially automate, is a hassle. If Apple can build a feature like this into the iPhone itself, it will be a smash hit feature, and, if it were something that only worked with Mac OS X, yet another impetus for iPhone/iPod users to switch from Windows. (My use of “can” is a reference to the challenge of getting phone carriers on board with it, not any technical hurdle.) The biggest limitation using NetShare is that because it’s a SOCKS proxy, it mostly only supports HTTP/HTTPS networking traffic. iChat can be configured to use a SOCKS proxy, but I’m aware of no way to get Apple Mail to use a SOCKS proxy for IMAP or SMTP, which means Mail doesn’t work using NetShare. But for web surfing, NetShare is a spectacular success. Yes, I’m aware that you can buy external Mac-compatible EVDO dinguses from Verizon, AT&T, and Sprint, but those are separate services that cost like $60 per month. With NetShare, I paid $10 one time and I can use it with my existing iPhone data plan without paying one additional cent. Performance is way better than the Wi-Fi service in most hotels.) The 3G’s ringer is louder. (I sometimes missed calls with my original iPhone because I didn’t hear or feel the phone ringing in my pocket.) The speakerphone sounds much better. As noted shortly after the 3G shipped, the color temperature of the display is different — warmer if you like it, yellower if you don’t. I prefer the original (cooler) temperature, but it’s only noticeable to me when compared side-by-side. Temperature aside, the screen seems identical to that of the original. Looking at the front face, the form factor is practically unchanged. The 3G is slightly wider overall, but since the display is the same size, there is now a small black border between the screen and the chrome, where previously the screen ran nearly chrome-to-chrome. The back is completely different, plastic instead of metal, and differently shaped. (I chose black, of course.) Aesthetically, I prefer the original iPhone case on all counts: shape, appearance, touch. The original iPhone is, to put it bluntly, sexier. I even liked the black plastic panel at the bottom of the original iPhone — it made it easy to tell which way the phone was oriented without looking at it, such as when pulling it from a pocket. From a practical standpoint, however, the all-shiny-plastic 3G has one significant and perhaps very valuable advantage: it is not slippery. There’s a tackiness to the iPhone 3G in hand. There is something to be said for the fact that the phone with the strongest brand in the world has no visible branding whatsoever on its front face. The home button on the 3G seems to require a more forceful push. The clickiness of my original iPhone’s home button is better. On the other hand, the clickiness of the 3G’s volume and sleep buttons is better. Apple sometimes seems to be the lone consumer electronics company that pays any attention at all to the tactile response of buttons. Battery life is the single biggest shortcoming. The simple truth is that the iPhone pushes the limits of what a device this size can do. Power consumption is perhaps Apple’s single-biggest engineering concern with the iPhone — both in software and hardware. Last year, when criticism of the original iPhone centered on the lack of 3G, Steve Jobs said it was about power. He was right. The iPhone 3G consumes power faster. However, the 2.1 OS update improved battery life dramatically. In particular, after upgrading to OS 2.1, the iPhone 3G does not seem to lose much power while idle. Part of it, too, is that because 3G is faster, you can do more in the same amount of time. So if you measure by time, yes, one hour of web browsing on EDGE will leave you with more battery life than one hour of browsing on 3G. But if you measure by the page, I think loading and reading, say, 15 web pages on 3G stands up just fine against loading the same 15 pages on EDGE. It just happens faster. Pt. 3: Coda “What’s great about this country is that America started the tradition where the richest consumers buy essentially the same things as the poorest. You can be watching TV and see Coca-Cola, and you know that the President drinks Coke, Liz Taylor drinks Coke, and just think, you can drink Coke, too. A Coke is a Coke and no amount of money can get you a better Coke than the one the bum on the corner is drinking. All the Cokes are the same and all the Cokes are good. Liz Taylor knows it, the President knows it, the bum knows it, and you know it.” — Andy Warhol So too with the iPhone. A billionaire can buy homes, cars, clothes that the rest of us cannot afford. But he cannot buy a better phone, at any price, than the iPhone that you can have in your pocket today. Once you get used to 3G performance, you’ll agree with this tweet from Adam Lisagor: “They should change the symbol for EDGE to stink lines.”↩
-
★ Regarding the Verizon and ‘iPhone Lite’ Rumors
There’s been much speculation this week regarding reports in BusinessWeek and The Wall Street Journal of talks between Apple and Verizon. To wit: that Apple is considering Verizon for a future iPhone and/or its mythical forthcoming tablet. This is not too complicated. Let’s just play “What’s in it for them?” Verizon — Would they want to sell some sort of iPhone model? Yes, of course. The iPhone has undeniably turned into a big deal. Verizon has nothing to do with it, and it is the single best competitive advantage held by AT&T, Verizon’s biggest rival. None of the iPhone rival devices Verizon has offered so far is any good or very popular (cf. the BlackBerry Storm), and the Palm Pre is exclusive to Sprint. AT&T — The iPhone means more to AT&T than any other phone it carries. Most people decide which carrier to buy a phone from, go there, then pick a phone. With the iPhone, people decide they want to buy one, and then they go to AT&T. Some number of iPhone owners switched to AT&T specifically and only because of the iPhone. In fact, there are some who switched to AT&T to get the iPhone despite the fact that, all things considered, they’d prefer to buy a phone from another carrier — often Verizon, which is widely regarded as having the best overall U.S. network coverage. It is very much in AT&T’s interests to keep the iPhone as an exclusive AT&T device for as long as it can. Apple — The iPhone matters to AT&T, but AT&T doesn’t really matter much to Apple. The U.S. is Apple’s (and the iPhone’s) biggest market, but it’s still just one country in a big world. In the just reported quarter, AT&T reported activating 1.6 million iPhones. But Apple reported selling just under 3.8 million total iPhones — so 58 percent were sold outside the U.S. AT&T isn’t Apple’s iPhone partner. They’re just Apple’s iPhone partner in the U.S. I think the U.S. tech press often overlooks this, hence some of knee-jerk skepticism that Apple would even talk to Verizon. Apple wants profit and they want market share. The trick is balancing the two. Surely Apple makes more money per iPhone with an exclusive deal, but they would sell more total devices if iPhones were available on both AT&T and Verizon. Yes, Verizon’s network is CDMA, not GSM, and so it would require Apple to produce different hardware. But there are some number of Verizon customers who won’t switch to AT&T but who would buy an iPhone from Verizon, and my guess is that that number is high enough for Apple to at least consider producing Verizon-compatible hardware. So, even if Apple would prefer to stick with AT&T exclusively, at least for another year, I’d find it surprising if they didn’t at least talk to Verizon just to hear an offer, and perhaps more importantly, to leak the flirtation to the press so as to keep the pressure on AT&T to offer Apple the best possible terms. But as for whether I think an iPhone on Verizon is actually imminent — as in “coming in the next few months” imminent — I doubt it. During Apple’s quarterly finance call last week, analyst Gene Munster asked why Apple has maintained its exclusive agreement with AT&T. COO Tim Cook said: On AT&T, Gene, we view AT&T as a very good partner. We believe that they’re the best wireless provider in the U.S. and we are very happy to be doing business with them. They have done a very good job with iPhone, they’ve put the full force and weight of their company behind it, it’s a major strategic thrust for them and so we’re very happy with the relationship that we have and do not have a plan to change it. And then Cook again, responding to a follow-up question regarding any “technical hurdles”: Well from a technology point of view as you know, Verizon is on CDMA and we’ve shown from the beginning of the iPhone to focus on one phone for the whole of the world and when you do that, you really go down the GSM route, because CDMA doesn’t really have a life to it after a point in time. Steve Jobs, famously, is known for pooh-poohing ideas or features only to turn around months or years later and declare them to be the best ideas or features ever, now that Apple has embraced them. Apple doesn’t announce big changes until it is ready to announce them, direct questions be damned. And so I wouldn’t count on Apple’s “not having a plan to change” the AT&T exclusivity lasting forever.1 But the CDMA comment does not sound like misdirection from a company planning to unveil CDMA phones this summer. That comment was specific, and it wasn’t something along the lines of we’re not going to do CDMA, but rather more along the lines of CDMA is on its way out industry-wide. That’s just not something Cook would say if Apple were planning to announce a CDMA phone in June — and without a CDMA iPhone, there’s no iPhone for Verizon.2 Ask again when Verizon’s next-generation LTE network is running, though. But that’s just the iPhone. If Apple is preparing to soon announce its supposed tablet / mediapad / whatever, and if said tablet / mediapad / whatever is going to support mobile broadband, it could well use EVDO from Verizon without contradicting anything Cook said about CDMA or the iPhone remaining exclusively on AT&T. (Brief Interpolation Regarding the Proper Perspective Regarding Any Rumored New Devices: Keep in mind that these tablet / mediapad / whatever rumors are growing to the point where if the WWDC keynote comes and goes without any mention of this device, the jackass contingent is going to blame Apple for not releasing it rather than blame the rumor reporters for being wrong. BusinessWeek’s report had the most details about purported new devices, but in terms of timing, only said “One of these devices may be introduced as early as this summer.” Point of this interpolation being that if — and this is a very real if — this really is a device Apple is preparing to release, fever-pitched rumors won’t make it appear any sooner than when Apple deems it ready.) Erring on the Side of Increased Market Share It’s my assumption that Apple’s long-term plan for the iPhone platform is patterned after Apple’s long-term plan for the iPod. Apple’s iPod strategy has been phenomenally successful, and there are many obvious parallels. The biggest difference is that the iPhone has succeeded far faster than the iPod did — Apple didn’t release the Windows version of iTunes until two years after the original iPod was released as a Mac-only peripheral. One of the key points in the history of the iPod was the release of the iPod Mini in January 2004. That’s when Apple expanded the iPod from a single product to a family of products, and the Mini proved to be a smash hit. The formula behind the iPod Mini was simple: Apple made a smaller, cheaper device with more or less the same technical specs as the original iPod from October 2001. Apple went on to repeatedly improve upon the iPod in two ways: on the high end by producing new devices with the same shape and price but with new features (additional storage, color screens, larger screens, video, etc.); on the low end by taking the existing features and making them smaller and cheaper. So here’s how I see Apple applying its iPod strategy to the iPhone. At some point the iPhone will expand to two form factors: A high-end iPhone with the same basic size and price as previous iPhones, but with significant new features. Obvious potential new features would be things like more storage space, more RAM, a faster CPU, an improved (and eventually video-capable) camera, 802.11n Wi-Fi, and superior battery technology. A new, lower-priced, smaller, and more adorable iPhone, with more or less the same technical specs as the original iPhone. Given that those specs include the 320  480 display, I wouldn’t expect something tiny, but remember that the original iPod Mini was “just” 35 percent smaller by volume than the then-current full-sized iPod. Shrink the iPhone’s forehead and chin and make it thinner — maybe a lot thinner — is what I’m thinking. Existing iPhone apps would run just fine on the new device, as it’d have similar, if not identical, CPU performance and RAM to previous full-sized iPhones. Such an iPhone sounds much like the “iPhone Lite” that BusinessWeek reported its source saw. The only question is when. Could be this year. Could be next year. But put me on the record for predicting it’ll happen before the end of 2010. The reason why Apple did this with the iPod, and why I’m convinced they’ll do it again with the iPhone, is that when it comes to managing the balance between per-unit profit and overall market share, Apple is determined to err on the side of market share. (Not as much with the Mac, however — the difference being that PCs are now a firmly established market.) Most gadget companies, when they have a smash hit on their hands, try to milk it. A typical company that found itself selling millions of $400 hard-drive-based digital music players would try its best to continue selling the same $400 hard-drive-based digital music players for as long as it could. Apple, despite an overwhelming 70 percent market share, aggressively added features and drove down its own prices, year after year after year. I’ve previously quoted the following passage from Steven Levy’s 2004 Newsweek interview with Steve Jobs, but it’s worth repeating here. The topic was the Mac’s long-stagnant (at the time) market share. If that’s so, then why is the Mac market share, even after Apple’s recent revival, sputtering at a measly 5 percent? Jobs has a theory about that, too. Once a company devises a great product, he says, it has a monopoly in that realm, and concentrates less on innovation than protecting its turf. “The Mac user interface was a 10-year monopoly,” says Jobs. “Who ended up running the company? Sales guys. At the critical juncture in the late ’80s, when they should have gone for market share, they went for profits. They made obscene profits for several years. And their products became mediocre. And then their monopoly ended with Windows 95. They behaved like a monopoly, and it came back to bite them, which always happens.” In the near term, Apple could fuel explosive iPhone unit sale growth just by reducing the entry price. But at some point, looking a handful of years down the line, expanding the iPhone’s U.S. market share is going to require going beyond AT&T. The only question is when. Worth a footnote: Munster never mentioned Verizon by name. He simply asked about maintaining exclusivity with AT&T. Cook brought up Verizon on his own.↩ The CDMA/GSM schism has blocked Verizon users from even unlocked iPhones. I’ve long wondered how much more prevalent iPhone unlocking would be if Verizon had a GSM network.↩
-
★ The Unsatisfying State of Twitter Web Clients for the iPhone
Twitter and the iPhone seem, at a glance, a perfect match: bite-sized micro-content paired with the world’s best mobile web reader. But here’s the thing: there’s not yet a single good iPhone Twitter client. The main things I want in a Twitter interface on my iPhone, roughly in order: A readable, attractive list of tweets, with the ability to page back to previous tweets so I can catch up if I haven’t looked at Twitter in a while. A good text input field for posting, including a live character count and responsive typing speed. The ability to mark tweets as favorites. An easy way to create @username replies. A way to view a list of replies directed at me. There’s not a single available Twitter client for the iPhone that offers all of the above. And the single biggest problem is out of the hands of third-party developers: paging. The API only returns the 20 most recent tweets, and the optional parameter to request previous pages (20 tweets at a time) has been marked “Temporarily Disabled” for over six months. This means when you use a third-party Twitter client, you see the 20 most recent tweets in your stream, and that’s it. It’s a deal-breaking limitation for third-party clients, because when you read your stream via the Twitter.com web site, paging works just fine. It’s unclear what the rationale behind this API limitation is — I can find no public explanation for it from anyone at Twitter. If it’s to prevent API clients from overwhelming Twitter’s servers by paging back through the entire history of users’ timelines (say, for the purpose of building a database for a Twitter search engine), this could be solved by allowing paging, but limiting the results to the most recent N pages, where N is a relatively low number like 10. That would suffice for common case of someone wanting to catch up on the last few dozen tweets from the people they follow. This limitation isn’t just a problem for Twitter web clients. Unless Twitter re-opens this ability in the API, it’ll impose a serious limitation on the coming-soon-to-the-iTunes-App-Store native iPhone application Twitter clients as well. Given that third-party iPhone applications won’t run in the background, each time you launch such a client you’ll see the 20 most recent tweets and no more. Twitter.com You don’t need a “client” to use Twitter, of course. You can just use the regular Twitter.com web site, which renders fine in Mobile Safari. It’s not, however, optimized for display on the iPhone. At its default size, it’s far too small to be readable: You can use the double-tap trick to zoom in on the content column, but you sort of have to double-tap at just the right spot near the top to get the entire column (including icons) sized perfectly. Once you’re zoomed in it’s a pretty good iPhone Twitter display: it looks pretty good, includes user icons, and displays 20 tweets per page. It also includes “Newer” and “Older” buttons at the bottom of the list for paging. At the end of each tweet are two buttons: a star for marking favorites and an arrow for creating an @username reply. However, at just 18  18 px, these buttons are far too small to be usable on an iPhone’s touch screen. Apple, in the iPhone Human Interface Guidelines for Web Applications, recommends that controls have a tappable area at least 44 px high.1 (For example, the back/forward/etc. toolbar at the bottom of the screen in Mobile Safari is 44 pixels high.) In terms of area, an 18  18 px button is just 16 percent the size of a 44  44 px button. But what really kills the usability of these buttons in Mobile Safari is that you’re typically viewing them scaled down. Twitter.com’s tweet list, not including the user icons, is 470 px wide; the iPhone screen in portrait mode is just 320 px wide. When zoomed to the width pictured above, these buttons are just 10 or 11 px wide. You’ve got to zoom significantly to use these buttons on the iPhone. For posting, the Twitter.com interface is a disaster on the iPhone. It works, but the size is all wrong. When you tap in the field to begin writing, Mobile Safari zooms the view to a width that cuts off half the field. If you zoom back out to a scale where the entire field is visible, the text is ludicrously small. Worse, typing in the field is dreadfully slow. The JavaScript Twitter.com uses to display the live character count works just fine in a desktop browser, but it’s way too slow for the iPhone. Worse, you can’t even see the character count while typing because it’s off the screen if you’re zoomed in close enough to make the text in the field legible. In short, Twitter.com is a perfect example of a web page that renders and works correctly in Mobile Safari, but which provides a user experience far inferior to what could be done with an iPhone-optimized web site. It seems weird that sites like Facebook and Amazon, which do so much more than Twitter, have iPhone-optimized interfaces, but Twitter does not. m.Twitter.com Twitter also provides a “mobile web” interface — a web interface for phones with rudimentary browsers. It used to be that to access this interface, you used a different URL: m.twitter.com. That was good. A few weeks ago they changed this, however, and Twitter is now using user-agent sniffing to automatically serve the mobile web interface to Mobile Safari, even when you go to the regular twitter.com domain. This is bad. You can change which version you’re getting in the footer at the bottom of the page. (Even if you don’t have an iPhone or iPod Touch, you can try out the mobile interface by using Safari’s Develop menu to set your user agent to Mobile Safari.) This setting is remembered with a cookie, but it doesn’t take long for the cookie to be forgotten. With the old scheme, where the standard and mobile web interfaces were specified by different URLs, you could (and I did) bookmark both separately, for use in different situations. The key appeal of Twitter’s mobile web interface is that it is very fast to load. One obvious reason is that doesn’t display user icons. Another is that the entire page is almost self-contained — the CSS is inline, it doesn’t use any JavaScript, and the only image is the small Twitter logo. It also only loads 10 tweets at a time. There’s no need for zooming, and typographically the display is spot-on — perfect use of Helvetica for the iPhone. (Unless you rotate the screen to landscape: if you do, the font blows up to giant size and stays there even if you rotate back to portrait.) There’s no way to mark favorites or create @username replies. The editing interface for the mobile version stinks. Most obviously, the field is way too small: it’s just one line high and doesn’t even extend to the full width of the iPhone screen. Typing performance is good, but that’s because it doesn’t use JavaScript at all, which means it doesn’t provide a character count. It does stop you from typing any additional characters once you hit the 140 mark, though. (It’s just a text field with the maxlength attribute set to 140.) A notable omission from the mobile interface is a way to view your @yourname replies. In the standard web interface you just tap the Replies tab, and all the third-party Twitter web clients support this as well. The 10-tweet display is a bit limiting, but like the standard Twitter web interface, the mobile interface supports paging. Better to have just 10 tweets at a time but with paging than 20 tweets at a time and no paging (as with third-party clients). EDGE network performance ranges from “kind of slow” to “really damn slow”; when tending toward the latter, the difference in loading Twitter’s mobile interface and standard interface is dramatic. That’s why it stinks that it’s set with cookie rather than the URL: if you’re currently set to use the standard interface (because, say, you were on Wi-Fi) but now wish to use the mobile interface (because you’re now on EDGE), you have to wait for the entire standard web interface to load, scroll to the bottom, zoom in, and click “Mobile”. With the old way, (a) they were bookmarkable, and (b) you could keep them open in two separate tabs at the same time — making it easy to use the standard Twitter interface most of the time, while switching to the mobile web interface with just two quick taps for use on EDGE. Hahlo Dean Robinson’s Hahlo is my favorite third-party Twitter web client. If it weren’t for the no-paging limitation in the Twitter API, I’d use it as my primary iPhone interface to Twitter. My biggest complaint about Hahlo itself is that its initial screen is a list of menu items, not a list of tweets. Perhaps this seems like a ticky-tacky thing to complain about, but the main thing you want to see when loading Twitter are the tweets. Waiting for the page with the menu to load before you then wait for the page with the tweets to load is annoying. (There’s a workaround for this, though, which I’ll get to in a moment.) Plus, the menu commands are a bit oddly named: “My Timeline” is a list of your own tweets. Twitter’s own parlance for this is “Archive”. Hahlo’s second menu item, “My Friends Timeline”, is what you want: a list of the 20 most recent tweets from the people you follow. But because Hahlo is entirely Ajax-driven, the URL doesn’t change from http://hahlo.com/, which means you can’t bookmark the tweets page you see after tapping “My Friends Timeline” on the main menu. However, you can get a bookmarkable list of tweets from Hahlo by loading this URL: http://hahlo.com/friends_timeline. Most users will never realize this is possible, because there doesn’t seem to be a way to navigate to that URL from within the Hahlo UI. Once you do see Hahlo’s tweet list, it looks nice. Good size, good spacing, good use of Helvetica. It includes user icons and has reasonably-sized buttons for marking tweets as favorites and for creating replies and direct messages to the author of a tweet. Editing is where Hahlo is a Viking. Typing speed is acceptable — not great, but good enough — and the best of any Twitter web client with a live character count. In most other iPhone clients with a live character count, typing feels dreadfully sluggish. Hahlo’s character count is mostly accurate — which means it’s best-of-breed for iPhone Twitter web clients.2 iTweet Colby Palmer’s iTweet is very much comparable to Hahlo. The most notable difference is the reversed light-on-dark color scheme. (I like it.) Like Hahlo, it offers a very nice tweet display, replete with nicely-sized per-tweet buttons for marking favorites and creating replies. iTweet’s UI is more sensibly laid-out and named than Hahlo’s. At the top of the tweet list are three buttons: Menu, Refresh, and Post. (Hahlo uses the word Update instead of Post, which is ambiguous: Update could just as easily be used to mean Refresh, in the sense of “Update this list of tweets.” You shouldn’t have to press a button to figure out what it does.) iTweet’s editing field looks good. Appearance-wise, it’s my favorite of any client — the text is eminently readable, slightly bigger and bold. iTweet also provides a live character count, but unlike with Hahlo’s, iTweet’s JavaScript hooks result in terribly sluggish typing speed. It doesn’t even come close to keeping up with my two-thumb typing speed, which is rather slow to start with. It doesn’t lose keystrokes, but the UI feedback for each keystroke is delayed by a fraction of a second, completely ruining the feedback that makes the iPhone’s on-screen keyboard tolerable. PocketTweets Justin Williams and Bobby Andersen’s PocketTweets uses more gradients than any other iPhone Twitter client. The icons look good, as one might expected from Mr. Andersen, but the text is too small throughout the entire UI. PocketTweets correctly defaults to showing you a list of tweets rather than a menu, and like iTweet, offers buttons for marking favorites and replying. However, once you mark a tweet as a favorite, PocketTweets doesn’t seem to allow you to unmark it. Also, the vertical Favorite/Reply button layout is worse than the horizontal layout in Hahlo and iTweet — I find myself inadvertently invoking Reply when I mean to tap Favorite. Another annoyance is that PocketTweets doesn’t create links from @username instances in the text of a tweet. In other clients you can tap on @username to display a list of that user’s tweets — useful for picking up the context of a reply. PocketTweets’s editing UI is also too small; it feels unnecessarily cramped. Typing speed is acceptable (on part with Hahlo), and it provides a character count. Unlike Hahlo and iTweet, PocketTweets doesn’t enforce the 140-character limit in the field. With Hahlo and iTweet, once you hit the 140-character mark, you can’t enter additional characters in the field. PocketTweets lets you run long, trusting you to notice the greater-than-140 character count. I like this design — it allows you to finish your sentence and then go back and edit the message to get under the limit. Sort of like writing an article with a word count — you wouldn’t want your word processor to stop accepting input once you’ve reached the limit. One last, truly minor niggle: the name “PocketTweets” is too long to fit as a web clip name on the iPhone home screen. It gets truncated as “Pocke…eets”. PocketTweets pre-dates the iPhone web clip feature, but it goes to show that iPhone app names need to be short and sweet. Thincloud Last and least is [Thincloud], from New Leaders. For reading, Thincloud’s font is too small, the text wraps back underneath the user icon on long-ish tweets, and there’s no way to mark a tweet as a favorite or automate a reply. For posting, there’s no live character count or enforced limit — Thincloud will let you blow past the 140-character mark with nary a warning, and you won’t notice until you see your truncated tweet in the list. (On the other hand, it’s the JavaScript for the character counting that seems to slow the other clients down; typing speed in Thincloud’s editing field is the fastest of the bunch.) SMS Twitter was conceived from the outset as a service for mobile phone users, even those with ridiculous old-timey pre-2007 phones without web browsers, using SMS. Twitter’s 140-character limit on status updates is a result of the 160-character limit of SMS. For reading tweets, Twitter might work OK via SMS if you only follow a very small handful of relatively quiet friends. But if you follow even just a few dozen people, I can’t even imagine how annoying it would be to have an SMS alert jingle your phone every time someone updates. To post status updates via SMS, you associate you mobile phone number with your Twitter profile (on your Twitter.com account settings page), and then send messages to the short code 40404. Typing speed is excellent in the iPhone SMS app, but, of course, you don’t get a character count. One technical advantage to posting tweets via SMS is that it works well even with sketchy signal strength or when Twitter’s web servers are under duress. Via SMS, I was able to post live updates from the hall in Moscone West during the Macworld Expo keynote in January. (Given that Twitter’s web servers were mostly down during the keynote, however, it’s questionable whether anyone was able to read them until afterward.) So If ever there was a web app that could be — should be — better on the iPhone than on a desktop browser, Twitter is it. But it isn’t. Twitter.com is the best site for reading tweets, even though it’s not iPhone-optimized at all, simply because it allows for paging. But it’s the worst site for posting. Hahlo and PocketTweets are the best for posting, but because the Twitter API doesn’t allow for paging, no third-party client is good for reading. The result is completely unsatisfying. Using one Twitter client for reading and another for posting is like getting your sandwich at Burger King and your fries from McDonald’s — convenience is the whole point. In landscape mode, Mobile Safari’s toolbar shrinks to 32 pixels high — a reasonable compromise for an orientation where vertical screen space is at a premium.↩ In every character counting feature I’ve tested on the iPhone, the count gets thrown off when you delete characters. Something seems broken regarding JavaScript keystroke event hooks in MobileSafari, at least with the Delete key.↩