iPhone Tips: Safari

Explore the Web broswer like an expert.   Jump to the Top Chances are that you've found yourself at the bottom of a very long web page, thinking that the only way to get back the address bar is to scroll, scroll, scroll your way to the top. Not so! Quickly jump to the top of any page simply by tapping the time.  read more

Explore the Web broswer like an expert.   Jump to the Top Chances are that you've found yourself at the bottom of a very long web page, thinking that the only way to get back the address bar is to scroll, scroll, scroll your way to the top. Not so! Quickly jump to the top of any page simply by tapping the time.  read more

  • So you just got an iPhone -- now what?

    Filed under: iPhone, HolidaysAll day on December 25, TUAW presents "Now What?" We've got first steps and recommendations for all the Apple gifts you (hopefully!) found under the tree today. Happy holidays! Congratulations, you've finally gotten an iPhone! It's either your very first one, or you've managed to upgrade to the iPhone 3G. As with any new hardware purchase, now you get to have even more fun selecting accessories for it. How to use your iPhone There is plenty of information out there if you're looking for a basic guide to the functions of your new iPhone. One of the best sources for free information is right here at TUAW. Here's a couple of tips to help you get started: Taking screenshots: Hold down the home button and then quickly press the sleep/wake button. You'll see a flash and hear the sound of a camera click, and a screenshot of your current screen will be placed in the Camera Roll under Photos. Back to home: If you're browsing a page on a home screen other than the initial one, press the home button again and it'll take you back to the first page of the home screen. You can also speed-scroll through your home screens by tapping to the left or the right of the white & gray page indicator dots at the bottom of the screen. Back to the top of the screen: In both Mobile Mail and Mobile Safari, if you've scrolled down to the bottom of the page and want to get back to the top easily, just tap the menu bar and your page will spring back to the beginning. Headphones If you're like a good many people, you want to replace the stock Apple earbuds as soon as possible. I love my Bose In-Ear headphones, for example. Shure is another excellent brand for purchasing earbuds, and their SE110MPA Sound Isolating Stereo Headset includes an inline microphone and a control button for receiving and ending calls. Sennheiser also makes a similar headset, but for a lower price. For the true audiophiles, there's Etymotic's hf2 headset. If you have $350 to spend, there is the Beats headphones by Dr. Dre. If you like Apple's headset but find that it's a poor fit, then it's worth the $9 to purchase a set of BudFits. They attach onto Apple's earbuds and then wrap around your earlobe for a very secure fit.Continue reading So you just got an iPhone -- now what?TUAWSo you just got an iPhone -- now what? originally appeared on The Unofficial Apple Weblog (TUAW) on Thu, 25 Dec 2008 15:00:00 EST. Please see our terms for use of feeds.Read | Permalink | Email this | Comments

  • ★ 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. ↩

  • ★ More Notes on Notes

    Some thoughtful feedback from readers regarding my analysis of the UI design of the iPhone’s built-in Notes app. Creation vs. Modification Date Sorting Regarding my assertion that sorting notes by modification date was the right choice, Glen Raphael1 writes: That would be fine for me if it were sorted chronologically by note creation time. That is what the Newton NotePad did and what the Palm notepad app did — quite sensibly. However, what Apple chose to do here was sort by note modification time. Which is insane. If I take notes in a variety of contexts over time, my notes are nicely sorted in historical order — the older notes are further down the list and notes taken at a similar time are in proximity to one another. So I can use my temporal memory to find things. Paper notepads in the real world work like that too. But on the iPhone if I ever go back to review my old notes and make any changes, those notes spontaneously jump to the top of the stack. That has two negative consequences: After reviewing and revising old notes, my notes are in a random order. Given that the chronological ordering has been violated and there’s no search feature, you simply can’t find old notes in a large stack. It doesn’t scale the way the Newton/Palm/everybody-else -in-the-known-universe approach does. If I scroll back to find an old note, revise it, and want to continue scrolling back to look at or revise the next note before that one… I can’t find it. Because the note I just changed has moved, it’s no longer adjacent to the one taken before it. This means lots of extra scrolling if I want to try to find the next note in series. In notepad apps on other platforms, I could easily scroll to the 40th newest note, delete a couple parts of that note I no longer care about, click/tap/button press once to get to the 41st newest note, fix a typo there, click/tap/button press once to get to the 42nd note and read it to refresh my memory, and continue down the stack — reading and revising as I go along. Try doing that with iPhone and you’ll want to throw the thing against a wall. As a result of this “feature” I no longer use Notes. I’ve switched to MagicPad and wish I could just delete Notes. Yeah, MagicPad has got copy/paste and font stuff, but for me the killer feature was simply that it allowed me via a settings preference to sort by note creation time, which is clearly the correct default. These are strong points. I don’t keep a ton of notes in my iPhone around at a time — I carry a paper notebook with me wherever I go, and which is where I jot most transient thoughts/items. I use Notes on the iPhone mostly for reference material I’ll want to come back to many times (which is to say, over a long enough period of time that I’ll have gone through several paper notebooks over that period), and for very specific temporary material like my airline flight reservation number for a trip. If you’re the sort of person who uses Notes for everything — say, if you’ve got dozens of notes — I can see how sorting by modification date might be maddening. It also occurs to me that sorting by creation date would fit better with Notes’s “looks like a paper tablet” visual metaphor. With a paper notebook, it’s easy to find something you know you jotted down “about a month ago” just by flipping back to the right spot in the notebook. In short, switching Notes to creation date sorting seems like a good idea. It would work better for people like Raphael, who keep a large number of active notes — and it would work just about the same for people like me, with a small number of active notes. Light users of Notes almost certainly wouldn’t even notice the change. Apple’s Private ‘default.png’ Cheat iPhone apps typically take at least a few seconds to launch, sometimes more. Developers can include an image to be loaded immediately after the app launches, named “default.png”. You can use this as a splash screen (more or less as a title card for the app), or, you can display the empty skeleton of the app’s UI (making it look like the real UI is starting to load, when in fact it’s just a screenshot of an empty UI). Apple’s own apps — which don’t have the same restrictions as third-party apps — have another option available, which I’ll call “dynamic default.png”. What many Apple apps do is take a screenshot of the current display when you quit, and overwrite the default.png file inside the application bundle with that screenshot. Then when next you launch that app, you immediately see the entire contents of the screen from when you previously quit — but it’s still just a screenshot, a static image. It looks like the app has launched instantly, but in fact you’ve still got to wait a few seconds for the app to restore itself to the point where it’s actually ready to use. I’ve seen third-party iPhone developers complaining that this trick is only available to Apple; they want to use it too. The technical reason why they can’t is that because application bundles are cryptographically signed, you can’t modify the contents of the application bundle (by, in this case, changing the default.png resource file) without breaking the digital signature. Apple could enable this feature for signed applications by providing for a way to specify a dynamic default.png that exists outside the application bundle, somewhere in the application’s private Library folder. But I don’t think these dynamic default.png files are a good idea in the first place. I fully realize that the user’s perception of performance is often more important than actual measured-by-a-stopwatch performance, but in the case of dynamic default.png files, I think it goes too far. It is frustrating to see a complete UI that looks usable but isn’t. Dynamic default.png files make application launch times look faster, but they don’t make them feel faster. I feel like a dolt every time I get tricked into uselessly tapping UI elements on a default.png screen. Notes uses this dynamic default.png cheat, and there are only very subtle indications to tell when the actual UI has replaced the screenshot (and is therefore ready to use). Several readers wrote in to complain about their frustration at not being able to tell when Notes is actually ready to use. Keshuv Prasad writes: The splash/loading screen for the list view is identical to the loaded view and gives no indication when one becomes the other. In note view the background lines blink when the loading screen turns into a loaded screen, but the pre- and post-loaded screens are identical. Photos, for example, displays a blank list as its splash screen and only shows the individual items (Camera Roll, Photo Library, etc.), after the app has loaded.  This makes it easy to tell whether the app is loading or has already loaded. Applying this same design to Notes would reduce frustration with not knowing whether or not the screen is responsive or not upon loading the app (note view would show a blank note, with the appearance of text indicating that it has finished loading). I too find the Photos model — where you just see a more or less empty shell of the UI upon launch — to be superior. That way, as soon as you see actual content, you know the app is ready to use. Prasad has another good suggestion: My second issue is how the notes are displayed in list view. There are up to 8 notes listed and the bottom one’s row fits exactly on the screen.  To use Photos as an example, it only displays 7 full rows, with the 8th row cut off.  Yes, the number of notes is in parentheses after Notes, but having the last row cut off (Contacts does this as well) would be a nice visual indicator that there is something below to scroll.  This is a minor quibble, though. In other words, because iPhone list views don’t show persistent scroll bars (which, on the Mac, provide an indication when there is more content below what is visible), it’s helpful if the row height is such that an even number of rows don’t fit exactly on screen. Good suggestion. In a previous Apple handheld platform universe, Raphael was the developer of NewtPaint. ↩

  • Jump to search field in Contacts on iPhone

    One of the new features in the iPhone 2.0 software is the ability to search your contacts (as well as an actual Contacts icon, instead of being forced to reach them from the phone section of the iPhone). The search field, however, is located at the top of the contact list, and is (strangely) not fixed in place. So if you scroll down, it scrolls off the top of the screen. To get it back, you can scroll up, of course, but that's time consuming. Instead, just tap the status bar (carrier, wireless strength, etc.), as you can do in Safari to jump to the top of a web page. This will take you to the top of your Contacts, bringing the search field back into view. I can't remember where I heard this one, though I think it was from a fellow Macworld writer during an iPhone 2.0 software conference call. Best as I can tell, though, it's not documented in the latest version of the iPhone user's manual (which is some 22 page...

  • ★ 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. ↩

  • More iPhone lessons

    I've received a lot of terrific comments and emails about my posting yesterday about Lessons from my son's iPhone. I'm dashing off to a meeting today, but here are some of the highlights:1. Why the iPhone feels so much more responsive. Anders Brownworth nailed the answer to this one better than I could have:I think the graphics on the Nokia are noticably slower than the iPhone because the iPhone has a dedicated graphics processor. So for example when you want to do coverflow or scrolling of contacts, the OS just tells the graphics chip that there is a surface with this picture or that text on it. Then the OS just tells the graphics chip where to position that pannel and it's up to the graphics hardware to actually render it. Of course the graphics hardware is much more efficient at rendering things, so it looks extremly responsive without ever burdening the main processor.This works quite will until the graphics subsystem runs out of RAM. Like, for example, if you load the NYTimes page in Safari and quickly scroll to the bottom before the OS has time to render the layout and send it to the graphics chip. At that moment you end up seeing a checker-board pattern. That's the pannel without rendered content on it. As soon as the CPU catches up, you see the content, but the interface never "freezes" while that happens.That's the revolutionary thing here. No other mobile device that I am aware of offloads graphics processing to specialized hardware. Hence, of course, Apple couldn't just purchase an off the shelf mobile OS. I think of this as a key competitive advantage for the time being. It's not something Windows Mobile contemplates yet but it is something Apple has had in OSX from day one.My initial reaction to this was, "Well, of course!" And then I thought about it for a few minutes and decided it was actually quite remarkable. After all, who ever imagined that a device designed to facilitate audio communication and playback would need a high-speed graphics processor? To me, this represents a clear example of Apple "Thinking Different" about the mobile phone market and innovating in a significant way.2. ATT Family Plans. I received a one email saying that this has been a sore point with many in their move to the iPhone. I would have to say it depends on your family plan. My friend Maribel Lopez had the opposite experience: the salesperson she worked with sold her a family plan to actually reduce her total bill, but that was because she was a new (Orange side) ATT customer, not an old (Blue) one. For those of us on the Blue side, there really is no alternative. You will be assimilated by the death star. Oh, by the way, I now have had two people tell me (and one of them was the salesperson at the Small World ATT store) that the Blue ATT network will be shut down in March 2008, so resistance really is futile.3. iPhones in Canada. One reader asked when we'll see iPhones north of the Canadian border. While we just heard today that the iPhone will go to Germany, Austria, and the Netherlands in addition to France and Spain, word on Canadian availability has been sparse. However, with the Canadian dollar appreciating against the US dollar, perhaps we'll see some progress there soon -- or not. Apparently the sticking point is the unlimited data plan, which Rogers has been resisting, but that's all I know.4. Why don't I have an iPhone? I have two answers to this question. One is that I have a start-up business and keeping that and my family afloat has taken priority over wonderful new phones. And secondly, I soon will, thanks to the generosity of an anonymous donor. And no, it's not Apple; even when I was a Forrester analyst, they never gave products away. I don't think they've changed that policy since.Technorati Tags:Apple, ATT, iPhone, Mobile phones, Canada, Family Plans, Lessons

  • Guessing what icons mean

    Create with Context's recent slideshow “How people really use the iPhone” reveals among other things how difficult it can be to intuit actions with confidence by icon alone. The slideshow notes that test subjects using Mobile Safari for the first time made some reasonable but wrong guesses about what several of the icons meant: They thought the magnifying glass to the left of the Address Bar meant “zoom this page”. They thought the Plus icon at the bottom of the Mobile Safari screen meant “increase the font size”. They thought the Book icon meant “read this page”. These are all perfectly reasonably interpretations of those icons. There are examples in Mac OS X as well. For instance, in Safari it's not immediately clear that the icon means “reload the current page”. You learn that this is so, but users might also initially believe it means “rotate the window to the right” or “rewind/go back”. Fortunately, icons with multiple possible interpretations usually make more sense one way than another, and so long as the associated action is not destructive, there's little harm done if the user is initially surprised. Safari's icon seems unlikely to mean “rotate the window to the right”, so it probably means “reload the page” and possibly means “rewind/go back”. But even when an icon might not represent an action as clearly as you think it does, once you click the icon the relationship between icon and action usually becomes clear. If I had a candidate icon for a frequently-used action but that icon might be misinterpreted by first-time users, I'd use it anyway if 1) it fit the action well, 2) the other possible interpretations were reasonably unlikely, and 3) the action wasn't destructive.

  • ★ The App Store, Day One

    A few random observations regarding the App Store and some of the apps: Download Counts On the iPhone’s App Store app, at the bottom of the details page for every app is a downloads count. Given that the only way to download a non-free app is to buy it, it more or less puts sales figures out in the open. These download numbers are not visible in iTunes — only in the App Store app. This is interesting for a couple of reasons. First, obviously, you can look at popular apps figure out how much money they (and Apple) have made. As I type this, Sega’s Super Monkey Ball game has been downloaded 10,955 times, and costs $9.99. That’s $109,440 in revenue in under a day — about $76K for Sega, and $33K for Apple. Second, for the handful of apps with free and paid counterparts, we can see how many people are willing to pay for the non-free version. The Iconfactory’s Twitterrific and Fraser Speirs’s Flickr client Exposure share a very similar model: both apps are available through the App Store in two forms: (a) a free version, supported by occasional ads from The Deck1, and a paid ad-free version for $9.99. As of this writing, here’s how the download counts look: Exposure 3,638 Exposure Premium 76 Twitterrific 13,638 Twitterrific Premium 322 So the ratios are very similar: 48-1 for Exposure, and 42-1 for Twitterrific. These numbers very well may change over time — for example, perhaps some users are treating the free ad-supported versions as the equivalent of demo versions, and, if they continue using and enjoying the apps, will spring for the paid premium versions in a few weeks. The download numbers don’t seem to be live, and a few developers who’ve been (understandably) obsessing over their numbers all day have told me that they’ve seen them fluctuate — both up and down. I suspect both the non-live updates and downward fluctuations are related to caching. It’ll be interesting to see if Apple continues displaying these numbers going forward. And it’ll be interesting to see what happens tomorrow, after the iPhone 3G goes on sale in Europe and North America, and after (I presume) the iPhone 2.0 OS update is officially released for existing iPhone users. Reliability Given the high daily traffic of the iTunes Store (for music and video), I’m not surprised, but the App Store seemed perfectly responsive all day long. Again, though, tomorrow — after the worldwide launch of the iPhone 3G and the 2.0 OS — will be the real test. I even bought and downloaded an app over EDGE, no problem at all. (Apps purchased over the phone network — EDGE or 3G — are limited to 10 MB, but most apps are well under that.) Re-Downloads If you accidentally delete an app you’ve bought, you can re-download it for free. The App Store UI doesn’t make this clear, but Apple describes it in this KBase article. What you do is act like you’re buying it again — tap the app’s price, and the App Store will recognize that you’ve already purchased it and ask if you wish to download it again. You can also do this from iTunes, to re-download an app to your computer that you originally purchased on your iPhone. Sandboxing Each app and its data are stored together, at least conceptually. When you delete an app from your phone, all of the files belonging to that app are deleted as well — preferences, data, support files, all of it is removed. Further, apps are not able to install files in the system behind your back. Delete an app from the home screen and there’s no sign of it left behind. This doesn’t mean data files are stored within an application’s bundle — they’re not. What it means is that because you, the user, don’t manage anything at the file system level, iTunes and the iPhone OS take care of all of it for you. Foolproof, almost — a very friendly conceptual design for typical users. AOL’s AIM App, and Third-Party Prefs in the System-Wide Settings App I’d sort of forgotten about it after the early demo back at the SDK announcement event in March, but one of today’s top downloads is an official AIM client from AOL — 43,226 downloads at this writing. I found it to be buggy as hell. At one point it was crashing for me on launch, endlessly, until I deleted it and re-installed. It doesn’t do links — URLs in a message aren’t tappable. Some messages came in blank — I could see who they were from, but there was no visible text. One other thing I noticed might prove important when using other applications, as well. AIM’s settings are not accessed within the app itself; rather, AIM adds a settings panel to the system-wide Settings app. What makes this so confusing, though, is that the first time you launch AIM, it (logically) prompts you for an AIM username and password. However, if you make a typo entering either, there’s no visible way to correct it — the account setup screen goes away after your first attempt. To change them, you need to leave AIM and open Settings, then scroll down (third-party panels are at the bottom). AOL is not being untoward in this regard; this is actually what Apple encourages iPhone developers to do. Based on the apps I’ve seen today, though, most developers aren’t doing it. That’s a bad combination — if most third-party apps display their settings screens themselves, then when users do encounter an app that uses the system-wide Settings app, they’re very likely to assume that the app simply doesn’t have any settings. Disclosure: Daring Fireball has been part of The Deck ad network since February 2006. ↩

  • iPhone 101: A user guide to take with you

    Filed under: iPhone, iPhone 101If you're going to be a new iPhone 3G owner this week, you might want to make a note of this site to help you get acquainted with your new mobile device. Apple has a guide to the iPhone available at http://help.apple.com/iphone/guide that you can view directly in MobileSafari, so you'll always have it when you need it. The guide has help for Phone, Mail, Safari, iPod, Applications, Settings, the Wi-Fi Music Store, and some Troubleshooting tips. I even learned something new: you can scroll to the top of web pages by double-tapping the title bar. Nice! Thanks, Rubinnz!Read | Permalink | Email this | Comments

  • ★ 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. ↩

The Comments Go Here

Software Releases