IconGrabber: easy icon extraction
Filed under: Blogging, FreewareThis one is a little bit of inside (blogging) baseball, but I know a lot of our readers blog themselves and so might find this tip handy. Ankur Kothari (whose Quicksilver customizations we've mentioned before) has cooked up an excellent little Quicksilver plugin called IconGrabber that does exactly what it sounds like. It allows you to easily create an image of an application icon at an arbitrary resolution in one of several popular image formats. Using a few...
-
â 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. ↩
-
â The Fear
The NDA is dead, yes, and good riddance, but there remain serious problems with the way Apple is managing the App Store. It boggles my mind that there remain so many people who don’t see this. This piece by Dan Kimerling at TechCrunch is one example; various of the reader comments on Jason Snell’s piece for Macworld last week are another.1 One factor, perhaps, is the tendency to see everything in terms of extremes. Black or white, good or bad. But this debate is not about wanting Apple to make radical changes, such as, say, changing the iPhone from a closed platform to a more open platform a la Android. There are reasonable arguments to be made that a more open iPhone platform would be good not just for iPhone developers, but for Apple and its shareholders. But those arguments aren’t what this debate is about. This debate is about wanting Apple to make minor changes — a slight but very significant course correction. Put another way, this is not about the big picture scope of what kind of hypothetical App Store (or Stores, plural) Apple should have created. That train left the station long ago. This is about the specific details of the App Store that actually exists, and the rules that govern it. I believe that a closed, controlled App Store can work, but by definition that requires developers to place trust in Apple. The problem is that Apple is managing the App Store in certain untrustworthy ways. And I mean trust more in the sense of stability than honesty — like in the way you need to trust a ladder before you’ll climb it. Here is a complete list of what Apple must do to increase developers’ trust in the App Store system: State the rules. Follow the rules. That’s it. This is so clear that even those who are arguing the other side — that Apple’s App Store stewardship is just fine as it stands today — have jumped through hoops in an attempt to argue that Apple’s exclusion of Podcaster was in fact in accordance with the iPhone SDK Guidelines. Kimerling, in his “Stop Complaining About Apple and the App Store” piece, writes: When you create the platform, you set the rules. If Apple wants to restrict iPhone applications to those that do not compete with features built into the iPhone, well, they can go right ahead and do so. It is right in the SDKâs user agreement. That’s just not true. The iPhone SDK Agreement, at least by the standards of legal contracts, is written in clear, straightforward English. (Apple’s lawyers, in the opinion of yours truly at least, are good writers.) The rules it lays down are clear. And Podcaster doesn’t break any of them. Given any set of rules, there will always be edge cases. Judgment must be rendered, and, inevitably, some will feel edge cases were judged the wrong way. But the reason iPhone developers (and prospective iPhone developers) are appalled by Apple’s rejection of Podcaster and MailWrangler is that neither app was near any edge defined in the SDK guidelines. Podcaster was rejected for duplicating the podcast features in iTunes and the iPhone “iPod” app. MailWrangler was rejected on the following grounds: Your application duplicates the functionality of the built-in iPhone application Mail without providing sufficient differentiation or added functionality, which will lead to user confusion. The word “duplicate”, in any conjugation, does not appear in the iPhone SDK Agreement. Not a word about it. And there is clearly no general rule about third-party apps duplicating the functionality of the iPhone’s built-in apps. PCalc, along with a handful of other calculator apps, duplicates every single feature of the built-in Calculator app. There are dozens of note-taking apps that compete with Notes; MagicPad goes so far as to use the same icon as Apple’s Notes app, just with different colors. There is an entirely category in the App Store — an entire category — for weather apps, several of which “duplicate” the entire functionality of the built-in Weather app. So, not only judging by the rules set forth in the iPhone SDK Agreement, but also by the existence proof of hundreds of apps currently published in the App Store that duplicate (which is really to say compete with) built-in iPhone apps, no reasonable person would have expected Podcaster or MailWrangler to be rejected. So their rejection is problematic on three fronts. First, the submission process is such that an app rejected at the conceptual level — one that cannot be tweaked or fixed to gain entry upon resubmission, but whose fundamental premise is rejected by Apple — such an app is only rejected after it has been written. The developer does all of the work to produce the app and only then finds out it was all for naught. Second, there are clearly rules which are not listed in the SDK guidelines. Third, in its explanations for the rejections, Apple is not stating what these actual unpublished rules are, and is instead offering as the reason this “it duplicates a built-in app” rule which, given all the aforementioned counterexamples that have been accepted into the App Store, isn’t actually a rule at all. The explanation is clearly false. Taken together, these three factors lead to The Fear, which is that developers cannot trust the App Store process. You can spend all of the time and effort it takes to build an app, follow every known rule, and still get rejected. From Apple’s perspective, especially, say, in upper management, it may be all too easy to look at what’s going on with the store — thousands of published apps, a ton of money changing hands — and not see the problem. In the big picture, from both a technical and marketing perspective, the App Store is a grand success. The problem is that the apps that are the most interesting, the most important, are the ones that take the most work to create. And the apps that take the most work to create are the ones that are most likely not even to be made in this environment, because the risk is greater. The more work it takes to create an app, the more you lose if Apple rejects it. Going back to the ladder analogy, the higher you’re trying to climb, the more you need to trust the ladder before you start. It’s not about a handful of developers who’ve had their apps rejected. It’s about all the other developers who are now spooked, and that the ones who are the most spooked are the ones who harbor the grandest, boldest, most innovative ideas. Interpolation Regarding a Theory on Which Apps Apple Won’t Allow Developers to Compete With In the absence of revised iPhone SDK Agreement from Apple, we can attempt to guess what the unpublished rules are. With Podcaster, for example, the “follow the money” rule of thumb leads to the conclusion that Apple will not allow any competition with iTunes, because iTunes is a profit source. This is why MailWrangler’s rejection is the one that puts The Fear in my heart. As unjust as the Podcaster rejection appears, if Apple really wants to prohibit competition with iTunes, even anti-competitively, you can at least see the thinking behind the decision. It’s foolish and unnecessary — the fact that iTunes is wide open to total competition on both Mac OS X and Windows hasn’t hurt it at all — and it also quite possibly invites some sort of legal challenge, but at least there is a logical idea behind it. But Mail? Why on earth should Apple care if some third-party email client for the iPhone becomes wildly popular? It makes no sense. iPhone users who use the built-in Mail app don’t pay extra to do so. Mail doesn’t tie users to Apple’s own MobileMe service. In fact, Mail offers specific setup help to work with Gmail, the service MailWrangler is optimized for. If you can make a replacement for Notes and Weather and Calendar, why not Mail? I have a theory. It is more, well, emotional than logical. But it’s the only theory I can think of that makes any sense at all and fits the available evidence. The theory is that there is an unpublished rule that Apple — and in this case, where by “Apple” I really mean “Steven P. Jobs” — will not publish third-party apps that compete with or replace any of the four apps in the iPhone’s default “dock”: Phone, Mail, Safari, and iPod. Go back to Jobs’s original iPhone introduction at Macworld Expo 2007. It was a masterful presentation. Carmine Gallo, writing for BusinessWeek, calls it Jobs’s greatest presentation; I agree. Gallo describes the moment it was unveiled: After laying the groundwork, Jobs builds up to the new device by teasing the audience: “Today, we are introducing three revolutionary products. The first is a wide-screen iPod with touch controls. The second is a revolutionary new mobile phone. And the third is a breakthrough Internet communications device.” Jobs continues to build tension. He repeats the three devices several times then says, “Are you getting it? These are not three separate devices. This is one device ⌠today Apple is going to reinvent the phone!” The crowd goes wild. This “three revolutionary products” pitch was inordinately effective. For one thing, live, in the hall, Jobs completely fooled the crowd, yours truly included. But then as he repeated the three product ideas over and over, while icons representing the three products rotated behind him on screen, faster and faster, it started dawning on us how we’d been tricked. By the time Jobs came out and said that it was just one device that encompassed all three products, everyone in Moscone West had come to that conclusion on their own — a nifty little way of making the crowd feel clever, as though we’d figured out a riddle. But this pitch also worked because it was true. All three of those products sound good on their own. All three in one device sounds insanely great. Jobs was introducing the iPhone simply by describing precisely what it was. A phone, a widescreen video iPod, and a breakthrough Internet communicator. The icons in the iPhone’s default dock represent the core functionality of the device. Phone, Email, Web, iPod. With nothing other than those four apps, the iPhone still would have been a hit. Not as great, but, still, great. Everything else the iPhone’s built-in apps do could be done, to some extent, through Safari: notes, calendars, weather, maps, stocks. There are a few minor exceptions. SMS is one example, but that’s really just an adjunct to the Phone app. Anything that relates to the phone network — voice or SMS — is unavailable through the third-party iPhone SDK anyway. You couldn’t write your own SMS app even if you wanted to. (Apple clearly has no problem with competing chat apps — there are several IM clients available in the App Store. That’s the same basic concept as SMS, but using IP networking.) And so my guess is that while there may not be any logic, there’s at least a notion, if only in Jobs’s mind, that these four apps are sacrosanct because they define the iPhone. Everything else, both from Apple and from App Store developers, is piffle, secondary to those four apps. Harry McCracken’s recent iPhone user survey indicates that iPhone users agree that those four apps comprise the most-used features of the iPhone. But the least essential of the four is Mail. You cannot place phone calls or play music and video from your personal iTunes library using a web browser, but can read and send email through it.2 Millions of people do just that every day, including, I’m sure, many of you reading this essay. And Google’s iPhone-optimized version of Gmail shows just how well it can be done. It’s not just good for web-based mail, it’s just good, period. And so this idea that Apple seems to have that Mail is particularly special is misguided. The Phone and iPod apps are special, because at a fundamental level they perform tasks that cannot be duplicated in a web app. But there’s nothing any more special about Mail than there is about, say, Calendar. Calendar, if anything, is more closely tied to Apple’s proprietary and commercial MobileMe service — Mail works great with any IMAP server, including Gmail, but Calendar only works for online syncing with MobileMe or Exchange. But Apple doesn’t seem to have any problem allowing Calendar competitors into the App Store. Notes Calendar is a $3 Lotus Notes calendaring client. Exchange Remote Calendar is a $10 is a $10 calendaring client for Exchange. If these are OK, why not a dedicated Gmail email client? The only explanation is that Mail is deemed untouchable and Calendar is not. The real test would be for someone to write a dedicated Google Calendar iPhone app — but given what happened to MailWrangler, it might be hard to find someone willing to try it. In short, my theory is that Mail is on the do-not-compete list not because there’s any strategic reason for Apple to do so, but simply because of a vague notion that Mail is one of the iPhone’s defining apps. This notion is wrong. Mail is important, but there’s nothing about it that needs to be protected from competition. End of Interpolation, Back to the Three Problems, Which, Due to the Grotesque Length of the Above Interpolation, I Will Remind You Are: (1) App Ideas Are Rejected Only After the Apps Are Actually Built; (2) There Exist Secret Unpublished Rules Regarding What Is Allowed; and (3) When Apps Are Rejected for Violating the Unpublished Rules, Apple Refuses to State Just What These Rules Are One thing that would make a difference would be a submission process whereby developers could submit their application ideas to Apple in advance, to find out if they’re OK. That’s how it works on game platforms from Nintendo, Sony, and Microsoft — developers submit a detailed proposal and wait until they get the green light before actually building the game. That sounds good, but there are problems with the idea. For developers, it would require an additional level of trust in Apple. Ideas are less valuable than actual implementations, but the more original an idea is, the less comfortable you are to share it. And for Apple, it would require significantly more work. They’d still need to examine and approve the actual shipping applications, but now they’d also have to examine and consider application proposals. The world’s hard drives are littered with abandoned unfinished software projects — there would surely be far more proposals submitted for consideration than there are actual iPhone applications. As it stands today, Apple is already struggling mightily to keep up with the work of approving new and updated application submissions — the typical turnaround time is between one to two weeks. Perhaps Apple could offer this as a service limited to ADC Select ($499) or even Premier ($3,499) members. The service is needed most by the developers who are considering the biggest apps, most of whom either are already paid ADC members or wouldn’t bat an eyelash at the cost of joining. It wouldn’t be democratic, but it might make it feasible. Platforms like Wii and Xbox ship maybe a few dozen titles a month, tops. The App Store has published 3,500 titles in just three months. (And it costs far more to join the developer programs for gaming consoles than the $100 iPhone SDK fee.) More important, though, is for Apple to address problems 2 and 3, by publishing in the iPhone SDK Agreement all of the rules they’re using to evaluate applications. If we’re not allowed to write email or podcast clients, say so. If something unforeseen comes up, Apple should make a decision, and then publish the new rule. Rules you disagree with are frustrating. Rules you don’t know about are scary. I will also note that, to my knowledge, not a single published iPhone developer has spoken out in favor of the App Store’s current rejection policies. Those developers who have spoken are against it. Those who see no problem are not themselves iPhone developers. ↩ Even if Apple were to come to its senses and allow third-party developers to write competing email clients, the built-in Mail app would hold one significant technical advantage, which is that it runs in the background. In fact, background processing is the one factor that unites the four dock apps. Phone, Mail, Safari, and iPod all continue running the background; no other apps, including those from Apple, do. ↩
-
Is Apple's MobileMe Secure?
Daniel Eran Dilger A recent article presenting how MobileMe works was been roundly criticized by at least three different bloggers. While the original article did not primarily address MobileMe security, the statements made about MobileMe's security do warrant some additional detail and clarification. In contrast, much of the criticism was wildly overstated to the point of actually misinforming users about the actual state of MobileMe and email security. Here's a look at what's involved. Inside MobileMe: Web 3 and Web Client-Server apps MobileMe's Web App Data Transactions are not SSL Encrypted. I enjoy reading John Gruber's excellent Mac resource, the Daring Fireball. It initially stated, âAppleInsider reports that the MobileMe web apps supposedly do use SSL, even though you donât see 'https:' URLs or the 'secure' lock icon in your web browser.â However, the referenced article did not ever state or even suggest that MobileMe's web apps use SSL or other forms of encryption when accessing the web apps for email and other services, outside of login and account settings. Gruber corrected the misstatement after being notified of this. For the record: Apple's MobileMe desktop email can be secured via encrypted SMTP and IMAP; Apple presents details on how to ensure this is set up, as users may not have this enabled by default. Address Book and iCal sync on Mac OS X is secured automatically when it transacts with Apple's server cloud. Windows apps use the same security when syncing their data via Outlook through iTunes for Windows. The iPhone and iPod touch also support encrypted email and all push messages are also secured via encryption. However, the MobileMe web apps are only secured by SSL through the initial login authentication session and again only when users access their account information to do things such as change their password, update their billing information, or order additional services. Outside of that, all email, calendar, and contact data that is exchanged between the web client and the cloud is not encrypted, and can be sniffed by anyone with access to the network (below, click to enlarge). What Unencrypted Web Apps Mean for Users. This means that as you send email, read emails, create new calendar items, view calendar events, and view contacts, that data is being sent in the clear across the Internet between the web browser and the cloud. This does not mean that if you access your email, anyone who might be sniffing traffic could intercept your account information, your login, your credit card information, or change your password. They also could not access anything you did not access yourself, so creating an email does not automatically allow them to read through your contacts, for example. MobileMe's limited SSL protection on its web apps presents a real (albeit unlikely to be widely exploited) security hole. However, it is important to note that Microsoft and Yahoo provide the same, limited level of SSL protection for their web services as Apple does; both Yahoo Mail and Microsoft's Live Hotmail send data in the clear after the initial login. Google has just started offering SSL protection by default for Gmail (below, click to enlarge). A followup article recommended that Apple should use the same IPSec-type of security for its MobileMe web services as it does for desktop sync. Other critics have noted that because Apple charges $8.25 per month for MobileMe, it should provide a better level of security than Microsoft or Yahoo and at least match Google. At the same time, it is important to recognize that adding SSL encryption does not automatically or even fully secure email. Appleâs secret âBack to My Macâ push behind IPv6 SSL is Not a Panacea. Blogger Jens Alfke, who works for Google, also took the MobileMe article to task. Alfke wrote that Apple's MobileMe apps not only do not perform data encryption, but also leave open the potential for rogue hackers to perform DNS forgery or phishing attacks that SSL could help prevent, or at least flag as a problem for the user when they occur. For example, a user trying to access webmail at me.com could hypothetically be redirected to a fake me.com by a bad DNS server, Alfke wrote. With SSL in place through the entire transaction, the user should at least be warned that the impostor me.com site did not match its known certificate. Without SSL, MobileMe web apps could therefore theoretically fall prey to a man in the middle attack, where all transactions were passed through a malicious user's third party control for tampering or viewing. Additionally, Alfke theorized that the web apps themselves could be replaced entirely by a fake site that pretended to be MobileMe in an Invasion of the Body Snatchers scenario. There are two problems with these scenarios. Alfke's assumption that MobileMe's âunauthenticated JSON exchangeâ could be easy to exploit, allowing redirect via bad DNS, is based in conjecture not fact. In response to his posting, Andrew Jaquith of the Yankee Group pointed out âthere are lots of ways for two parties keep rotating secrets on both sides of the wire without disclosing them. See, for example, RFC 1938. I donât know exactly what Apple is doing with JSON, but dismissing it just because it isnât encrypted doesnât prove anything.â Jaquith also described why SSL is not good for âverifying that software is 'genuine' or that a website is what you expect,â as Alfke claimed in dismissing Apple's security architecture for its MobileMe web services. Jaquith presented a scenario that would result in âa supposedly sniff-resistant [SSL] session that is still nonetheless 100% hosed.â Re: MobileMe Webmail Security â There Is None â Thought Palace Security through False Assurity. On top of that, even in cases where SSL could identify that something bad was happening, the only protection SSL really provides is to throw up a warning about security certificates that most non-technical users browsing at Starbucks would likely just click through to dismiss before happily giving away their credit card info, thinking they are safe because they are interacting with the âSSLâ icon on for a website. When Apple transitioned from .Mac to MobileMe, users were presented with a SSL warning related to mac.com being redirected to me.com, and nobody seemed to even notice. SSL warnings are similarly not going to secure users who do not understand the security issues involved when they are sent to me.info or me.192168.com, or redirected by a malicious DNS to a server pretending to be me.com but failing the SSL check. Therefore, the benefits of adding SSL were greatly overstated by some critics, who also failed to even consider its drawbacks and limitations. If Apple simply added SSL, it certainly would, as stated in the original article, provide a âfalse sense of security that distracts from real security threats.â At the same time, the original article also understated the value SSL would provide web browser users. Adding SSL security throughout MobileMe's web apps, particularly those that deal with private data, would likely provide benefits that overshadow the added overhead. Despite that, it would not âsecureâ email for users, as described below. Never Cry Poppycock. While the original article was not purporting to be a tome on security, another response to it claimed special expertise in security. However, the author not only greatly overstated his case, but also resorted to unprofessional language in demeaning and dismissing the whole of an article just because he took issues with a minor portion of it. Rich Mogull's âMobileMe Web Interface Insecure, But Other Apps Get It Right,â published by Tidbits, provided some interesting comments on the subject, but began with an unnecessarily arrogantly overstatement of criticism that misstated the point and the context of the article in order to attack it as âpatently falseâ âtechnobabbleâ âpoppycockâ and so on. Mogull didn't contact the author of the original article prior to writing about what he claimed was so wildly inaccurate. In addition, his own presentation is flawed and overstated in ways that are far more misinforming than any disputed details in the original article. TidBITS Safe Computing: MobileMe Web Interface Insecure, But Other Apps Get It Right Consider the Context. Mogull jumped upon a quote taken out of context, which was actually talking about how MobileMe and other JavaScript apps manage security related to JSON transactions. The context of the quote was the potential threat posed by sending self-executable JSON as opposed to simple XML data: âBeing able to inject executable code into a system from malicious sources is a primary security problem. For that reason, web apps that transmit data using JSON have to authenticate with the server and regularly perform security handshakes to ensure that the data being sent back and forth is indeed coming from and going to a trusted source.â Mogull not only ignored that context, but only linked to the second page of the article, where the quote appeared without its immediate context. This enabled him to present that the comments on how JSON is secured were entirely about âwhy SSL was unnecessary,â which was not the point of the text at all. Quibble vs Patently False. The article presented that there was âunnecessary panic among web users who have equated their browser's SSL lock icon with web security;â that is accurate. While SSL encryption provides an additional layer of security, is not infallible. SSL security requires faith in fallible architectures that have regularly published vulnerabilities. Suggesting that SSL would be a panacea for webmail is false for a number of reasons: SSL can be spoofed; the browser only presents a cryptic warning when that happens, which many users would not know how to handle if it were being spoofed; and the larger fact that even SSL-secured web email is not really secure. The original article also correctly pointed out that SSL could provide a âfalse sense of security that distracts from real security threats.â Users who think that SSL web-based email is secure and therefore appropriate for sending confidential information are in for a rude awakening. Email is not secure, and carefully securing part of the email transmission is like only locking three doors of your car. It's better to understand that thieves can take anything in your car rather than to lock three doors and assume that you can leave valuables on your seat that cannot be taken. Mogull is arguing that Apple hasn't provided a functional lock on the driver side door of its webmail service, ignoring the fact that Internet email has no locks on the tailgate or the rear doors at all. This is penny wise and pound foolish security, and can be judged as the âpatently false technobabble poppycockâ that he quickly used to dismiss an article that was only touching on one aspect of security in a larger piece that was really addressing how MobileMe works as a service and the future potential it holds out. Mogull's reply was entirely about security, but it delivers the wrong message. It's not just easy to quibble about some of Mogull's details; his primary argument that the original piece was ridiculously wrong is just false, primarily because he overstates it in such an over the top, arrogant way. SSL is Not Evil. Having said that, the original article did understate the value SSL can add in securing webmail. SSL is useful in protecting users at the point where they will be most vulnerable when checking webmail, as they are more likely to be at a public terminal or perhaps using unsecured public WiFi when using the web rather than desktop clients (which are secure using encrypted transmissions) or an iPhone (similarly secured). SSL web apps would provide MobileMe users a similar level of security; Apple currently does not present this throughout the entire webmail session, only when the user authenticates and if they enter account details to change their password or order new services, as noted previously. With SSL, webmail addressed to other MobileMe users, as well as access to one's own contacts and calendar would be very secure. Email to other domains would continue to be exposed to Sending email is like sending a postcard: anyone intercepting the postcard on its way to the post box, from there through the mail system, or on the way to the recipients mailbox will be able to read what's written on it. Encrypted email is more like a letter written in code inside of a security envelope: it would be far more difficult to view its contents. However, SSL email only provides security for part of the trip; it's like carefully guarding your postcard until you drop it in the mailbox. This will prevent casual eavesdroppers from seeing what you've written, but won't protect you from having your postcard read from that point on, because it is wide open throughout the rest of the trip. In addition, when using a public computer or improperly secured WiFi network, the SSL security provided to a webmail user can't be trusted. A public PC is just as likely to have a spyware keylogger installed (if not more so) than a malicious hacker listening in on the transmission remotely. Your emails could therefore be spied upon before they were sent through the secure SSL pipe to the cloud. Similarly, using an unsecured WiFi connection opens a user to security issues that far outweigh having your email transactions possibly sniffed. Additionally, across the industry there are few webmail providers who deliver greater security that Apple's MobileMe. Google just recently added SSL, while Microsoft and Yahoo provide similar security to Apple's web interface in MobileMe: SSL encrypted authentication and account protection (you can't change your password in the clear on MobileMe, only in an SSL session). Doth Protest Too Much, Methinks. So while SSL isn't worthless, it does not present the bulletproof panacea that Mogull suggests it would in his over the top, excessively arrogant, one-sided attack piece. While the original article's understatement of the benefit that SSL could bring to Apple's MobileMe webmail could rightly be criticized, it did not say that the existing webmail service was secure. Instead, it said email was not secure and shouldn't be trusted, and that SSL could provide webmail users with a false sense of security. Mogull presented this in a mocking, simplified paraphrase as, âwe think SSL would bog down performance without providing security.â He then concedes that he has overstated his own arguement by agreeing that SSL would have a limited impact on securing users, saying, âWhile there's a reasonable, if small, risk someone might sniff your connection when you are out in public, the odds of a redirection attack are extremely low.â Mogull could have presented his last paragraph, essentially warning users that MobileMe's web interface exposes them to unlikely but theoretically possible dangers, and explain that Apple's expanded use of SSL could help secure its webmail service from some of these kinds of attacks. Instead, the solution he demand would only provide limited benefits to users, while providing that suggestion that webmail is more secure that it really is in practice. This would suggest to user a greater level of security than would actually suggest, a far worse problem than acknowledging that email is simply not secure and should not be treated as such. Ridiculing the original article for presenting the fact that SSL is not a panacea, explaining unrelated facts about JSON, and describing that email shouldn't be trusted was all entirely unnecessary, and really just presented in a unprofessional fashion. Did you like this article? Let me know. Comment here, in the Forum, or email me with your ideas. Like reading RoughlyDrafted? Share articles with your friends, link from your blog, and subscribe to my podcast (oh wait, I have to fix that first). It's also cool to submit my articles to Digg, Reddit, or Slashdot where more people will see them. Consider making a small donation supporting this site. Thanks!
-
10 ways to get the most out of Quick Look
Filed under: OS, LeopardWhen Steve first demonstrated Quick Look, I though it looked gimmicky. Interesting, for sure, but nothing I'd use regularly. Much like Star Wars Episode I: Fun when viewed for the first time, but I'll never watch it again.Three months later, Quick Look is my favorite feature of Leopard. It's convenient, useful and very fast. With a tap of the space bar, I can identify files in the Finder without having to open a separate application.Of course, it goes beyond that. With a little effort (and in some cases, plug-ins), you can get even more out of Quick Look. Here's how. Identify files on remote machines. I've been using Remote Desktop at my day job for a couple of years now. With a few clicks, I can observe or control a remote Mac. Leopard brings this convenience to home users with Screen Sharing. It's useful, but files appear quite tiny when viewed on this screen-within-a-screen (and titles even smaller). Fortunately, Quick Look makes things much more legible. Preview the contents of Zip files (plug-in required). BetterZip and the Zip Quick Look Plug-in both let you view the contents of a zipped file with Quick Look. In fact, Zip Quick Look's display is dependent on a HTML file which you may alter to your liking. Here's how to install Quick Look plug-ins. Preview the contents of a folder (plug-in required). Much like BetterZip and Zip Quick Look, the Folder List plug-in lets you preview the contents of a folder. You can also customize its HTML-powered display and show or hide hidden files or time stamps. Examine snippets of code with syntax highlighting intact. Here's another tip that requires a plug-in. Qlcolorcode lets you preview your code with all the helpful highlighting you expect. Examine files in the trash. Until Leopard, the Finder's trash would keep its contents to itself. Anything you wanted to examine had to be moved back to the desktop. Fortunately, Quick Look lets you preview trashed items. Now you know precisely which item to yank out of there. Prep your iWork documents for use with Quick Look. When you create a document with Numbers, Pages or Keynote, you can ensure that its preview will display the proper formatting by selecting the Include Preview in Document check box whey you save (or turn this feature on by default in the general preference pane). Enhance TextMate. TextMate is the editor that geeks everywhere love (including the geeks at TUAW). Ciarán Walsh has written two Quick Look plug-ins for TextMate that let you preview items in a project or render Quick Look previews (for certain file types) using the TextMate syntax highlighter, respectively. Preview fonts. Open a Finder window, select Cover Flow view and navigate to the font you're interested in. Click the space bar and presto! Instant preview. Quick Look and Cover Flow. I love the combination of Cover Flow and Quick Look. Open a bulging folder in the Finder and select Cover Flow view. Tap the space bar to preview the 1st file and then use the arrow keys to move the next one and so on. You'll stay in Quick Look mode! Very cool. Send images to iPhoto. When viewing an image with Quick Look - either from the Finder or attached to a Mail message - you'll see a tiny iPhoto icon at the bottom of the window. Click it to send that image to iPhoto. I hope you found these tips useful. And I still dislike Episode I.Read | Permalink | Email this | Comments
-
Where's the WebClip icon?
Filed under: Cool tools, Odds and ends, TUAW Business, WIN Business, Developer We've gotten a plethora of tips asking that we make a WebClip icon for iPhone & iPod touch home pages for TUAW. And we hear you. In fact, one sleep-deprived Macworld-covering TUAW blogger created a webclip icon (pre-empting all the tips -- which we're eternally grateful for nonetheless). As our server gurus get the icon fixed in place, we thought we'd share with you some handy links both for making icons for your own site, and perhaps to find one for TUAW in the meantime. Waiting for a website to gain a WebClip icon? There's a load of sites available to either help you find an icon that's already been made -- such as WebClipMe! or the WebClip directory. clipalizer goes one better, allowing you to upload your own (correctly sized) PNG image and then use that as a webclip icon.So how do I create my own WebClip icon? A WebClip icon is basically a 57-pixel-square PNG image called apple-touch-icon.png placed at the root of your server's web-content directory (though the Apple Developer Connection site lists a way that code-savvy users can specify a custom location for it, should they so choose). Whilst the icons appear rounded on the iPhone, you don't need to worry about creating curved corners, or even apply a button-esque mask in Photoshop: iPhone takes care of all of that -- "Safari will automatically composite the icon with the standard "glassy" overlay so it looks like a built-in iPhone or iPod application."Thanks to all those who sent us pleading emails! Read | Permalink | Email this | Comments
-
WWDC 2008 Winners: Where Are They Now? â Macnification
Admittedly, not everyone needs a Mac-based application to manage pictures taken by a microscope. If you're a scientist, though, you probably won't find an app that's as useful and well-designed as Macnification. More than just an image organizer, this app lets users edit and analyze pictures from digital microscopes, attach important metadata , and even create time-lapse movies. Apple must also think Macnification a pretty nifty app since it presented its developers Peter Schols and Dennis Lorson with a design award at Apple's Worldwide Developer's Conference this summer for Best Mac OS X Leopard User Experience. As part of a series of posts that take a look at this year's WWDC winners, I caught up with Schols to find out how to design a good user experience, and what it takes to be a good Mac citizen. Here's what he had to say. TAB: What gave you the idea to create Macnification? How long was the development process? PS: My background is in biology and bioinformatics. While working in the lab to obtain my PhD, I made intensive use of electron microscopy. However, once the images were acquired from the electron microscope, I had to rely on a plethora of applications to manage them. I organized images in the Finder or in iPhoto, adjusted them with Photoshop, analyzed them with ImageJ and added scale bars with yet another application. Having to use half a dozen applications makes things very complex and error prone. In addition, most of these applications are designed for general purpose imaging: most of them are not able to deal with microscope metadata, for example. Therefore, I always dreamed of having one, easy-to-use application for this entire workflow. That's how Macnification was born. Development started in November 2006. Due to many new technologies in 10.5 that could benefit an image management application, we immediately opted to make Macnification Leopard-only. However, Leopard was still very much under development in the fall of 2006, so the initial development did not progress as well as we would have expected. It was only after we received the Leopard developer preview at WWDC 2007 that we could progress faster. We finally released Macnification 1.0 on May 6 2008, after 18 months of development. TAB: How did winning the Best User Experience award benefit the Macnification project? PS: The impact of an Apple Design Award cannot be overestimated. Needless to say, it has a positive impact on sales, which nearly doubled after the ADA announcement. Furthermore, it really makes the product stand out, especially in a niche that is not really known for excellent UI design. Most importantly though, it was a major recognition for Dennis and myself after 18 months of hard work. TAB: Tell me a little about what goes into designing a good user experience when developing an app. PS: We have put a lot of effort into planning this application: the first months of development were spent almost exclusively on planning the application's mission statement, the main workflow and the application's key features. Especially for a project this size, it's really important to know exactly what you are going to develop, who you are going to develop for, how it will be used and what your users need. Crafting a mission statement for the app, as John Geleynse emphasizes in his WWDC user experience presentations, is one of the best ways to make sure you do not overload the application with useless features or features that are not focused on the task at hand. Of course we had an advantage there: due to my experience with electron microscopy, it was much easier to know what users really need. Once the mission statement has been established, we start thinking about the core user experience. What are the metaphors the user is familiar with when trying to accomplish tasks? How can we use the metaphors in the interface to make the application as easy-to-use as possible? Once the core UI is done, we start adding relevant but secondary features and we try to give them a place in the core UI in a way that makes them seem like natural extensions of the core UI. Needless to say, this is an iterative process: sometimes you find that it's very hard to add additional features without making the UI too bloated. That's probably because the core UI is not well designed or because the metaphors being used are not in sync with the user's mental model. TAB: What was the biggest thing you learned by attending WWDC? PS: I have been attending for the past 7 years and Dennis has attended for the past 2 years. The presentations are very interesting, not only for the technical details but also because they paint a much clearer picture of where Apple is heading than you would get from visiting apple.com or reading Mac news sites. If there is one thing you should know as a Mac developer, it's probably where Apple is going. For example, by attending WWDC, we knew that Leopard would have extensive support for image handling through ImageKit. Being able to use this new technology long before it is being shipped in the final OS is a major advantage. The possibility to interact with Apple engineers and user experience specialists is probably the most important reason to attend WWDC. In 2007, we had a UI-review of Macnification at WWDC. This review helped us tremendously in making some final UI decisions and in solving a couple of UI problems we kept thinking about. In addition, it's a great way to check whether you are still on the right track UI wise. In terms of code, we had similar experiences. We worked very closely with the ImageKit team to make the best use of this technology. It was a mutual process: the ImageKit team was glad to see their framework being used in a scientific project and by using ImageKit we could help it improve while receiving some extra tips and tricks to improve Macnification itself. TAB: What would you tell someone who hopes to one day win a design award at WWDC? PS: I already mentioned some key points, like the importance of crafting a mission statement, talking to users and trying to find out what they need, trying to follow their mental model and creating a simple core UI. All this is very important, but at the same time your application won't win a design award if it's not a good Mac OS X citizen. Your application must feel right at home on Mac OS X in terms of visual appearance, interaction and technology integration. It's important to integrate with other applications and with the OS. For example, Macnification uses Core Animation, ImageKit, PDFKit, Quick Look, Objective-C 2.0, Time Machine, QTKit, Core Data, Spotlight and Core Image. It works well with Numbers and Mail and it has support for multiple processor cores. Your application should do things that are new to the platform or that really help to push the envelope. With Macnification, for example, we are releasing the first scientific imaging application to offer non-destructive image editing, taking advantage of Core Image. We even use Core Image to provide scientists with the fastest EFI implementation on any platform. Additionally, we use Core Animation, not just to show some nifty animation effects, but also to make navigating huge image stacks much more intuitive. The take-away point here is that you should not just integrate technologies for the sake of integration, but make sure they offer a real advantage for your users. Finally, you should get in touch with WWDR at Apple for a user interface review. It can massively improve your application. TAB: Obviously Manification is tied to microscopic not camera images, but do you plan to release an iPhone App at any point that would allow users to access some of the functionality of the main app? PS: It's something we think about. This currently isn't a high priority for our users, but it's definitely something we keep in mind going forward. TAB: Is there anything else you'd like to add? PS: Most Mac news sites only publish a list of Apple Design Award winners. As there is so much more to winning an ADA, it has been great to be able to share our experience! We would like to thank the Apple Blog for giving us that opportunity! Concentric Hosted IT Solutions and Web Hosting Click here to save cost on your IT demands
-
Flickr Find: the Fluid icons pool
Filed under: Software The team down the road from me at Carsonified have been doing it, and you can do it too. Fluid is a fantastic free app that turns any web site into a self-contained application on your Mac. If you want to keep your webmail outside your normal web browser, Fluid is what you need. Thing is, all the apps it creates need icons, just as any app in your Applications folder does. By default, Fluid grabs the .ico files it finds on web sites and uses them as icons, but they don't scale well. Where can you find decent alternatives? The answer is the Fluid icons pool on Flickr, where a busy community of Fluid users have been busy making a selection of beautiful icons that work perfectly with any Fluid SSBs (Site-Specific Browsers) you've created. The icons in the pool might look weird to start with, but that's because the PNG originals have been converted to JPG format by Flickr's brain. To make use of an icon you like, make sure you view and download the full-size original, which will be the PNG file you need.Read | Permalink | Email this | Comments
-
Photonic goes 1.0
Filed under: SoftwareThe last time that we took a look at Flickr upload utility Photonic, it was still in beta. Photonic's developer Barton Springs Software has just released Photonic 1.0 -- a major step up from the beta. In addition to the various bug fixes, Photonic also received the following features: The ability to add favorites and photosets New option to send FlickrMail to the owner of a picture via a contextual menu on photos in a stream New option to go to the photo's page is now a contextual menu Drag and drop images to the application icon or to the source list to add the image to your upload queue Double click now zooms in on image rather than going to Flickr Set favorites on Flickr now New tabbed preferences window New preference for the number of concurrent downloads (previous default was 3) Possibly the best new feature that has been implemented for 1.0 is the full screen preview. You can now see your (or your friends) Flickr photos full-screen; this is really handy for when you want to show off a set of pictures. Photonic is available as a trial download from the developer's website, and it's currently purchaseable at a special price of $20 until March 15th.Read | Permalink | Email this | Comments
-
VMware Importer makes migrating from Parallels a snap
Filed under: OS, Software, SwitchersIn our post yesterday on VMware Fusion 1.1 we mentioned that VMware had also included a beta of their new Importer application. However, after using it tonight, I thought it was worth a separate post of its own, because it makes migrating from Parallels to Fusion incredibly easy. The amazing thing is that I converted an old Parallels 2.5 WinXP VM which Parallel's 3 itself had not been able to import successfully!Basically, when you start the Importer it gives you a window in which to drop the Parallels .pvs file (just Win2000, WinXP, Win2003 Server or Vista at this time). It asks you where you want to save the new Virtual Machine and a few minutes later, boom it starts right up in Fusion -- no muss and no fuss. For me the amazing thing was that I had previously tried to import the same image into Parallels 3 and it failed. So basically the upshot is this: if you're running Parallels, but you'd like to give Fusion a try, the barrier to entry has now dropped to next to nothing (besides the hard drive space). I bought Parallels for my Intel Mac as soon as it was released,but given my experience with Fusion (especially with the downloadable appliances), I think VMware has a convert. I fully recommend giving it a try. The VMware Importer is a free download. It's also supplemented by the VMware convertor which will create an image of a working PC that can then be imported into Fusion as a VM.Read | Permalink | Email this | Comments
-
â 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. ↩