From San Francisco

The Mac and iOS development community just finished attending five days of intensive sessions led by Apple engineers. Developers are now heading home to start implementing everything they’ve learned this week. Like any other deluge of information, I think it’s going to take a while for everything to sink in. From my point of view, some of the most exciting technology got the least attention, and I’m still thinking about what it will all mean for what I’m working on during the next year or two.

One thing in particular seems to be changing fast. It used to be widely agreed that Apple had fallen off the clue train when it came to helping us create rich experiences with web applications. Now, however, the technology has finally caught up to where Apple wanted it to be when the iPhone first launched. The company was loudly criticized three years ago for telling developers that web apps were a perfectly good way to develop iPhone apps. Three years later, it finally is.

Offline storage and CSS transitions are just the beginning. I strongly suspect that within a year or two, we won’t be so critical of that sandwich we were served back in 2007. I’m excited about what Mobile Safari will be able to provide web app developers.

Maybe the effects of the Reality Distortion Field™ haven’t yet worn off, but the future looks good from here.

Complete and Concise

Marco Arment brings up an interesting point regarding section 3.3.2 of the iPhone Developer Agreement in his tweet about interpreted code in spreadsheets. The section of the Developer Agreement in question reads, “no interpreted code may be downloaded or used in an Application except for code that is interpreted and run by Apple’s Documented APIs and built-in interpreter(s).” While the language is clearly intended to ban interpreted languages like JavaScript, Lua, or C# from the iPhone, it’s surprisingly vague about what constitutes running code.

I don’t think there’s any question that developers are allowed to link to arbitrary regular expression libraries. However, regular expressions (like all the regular languages) also define computation, so presumably compiling a user-generated regular expression and running it in your application would violate the letter of the law. (This of course depends on whether you’d consider regular expressions “code.” If code is a sequence of symbols that define the actions of a machine, regular expressions would very much fall in that category.) And yet Apple has not, to my knowledge, rejected an application that uses regexps. Because it would be silly. After all, a regular expression’s limited ability to loop (they’re not Turing-complete) guarantees that it will halt. And the spirit of the law intends to prevent code from looping infinitely or otherwise misbehaving.

Once we open the door to some forms of computation, various interpretations of section 3.3.2 might allow all kinds of middle ground. Spreadsheet formulas, SQL queries, and parsers of context-free grammars all fall below turing machines in terms of computational complexity. The problem is that we don’t know where Apple draws the line. A spreadsheet application (Apple’s at least) makes the cut. An application that links to a custom SQL engine library might squeak by. But I imagine an iPad app that included a Charity interpreter—despite Charity’s property that its computation always terminates—would be straight up rejected.

Unfortunately, it’s unlikely a developer will test the waters on this one, and we’ll all be left guessing where the dragon lies. Apple is equally unlikely to draw a line in the computational complexity hierarchy which we May Not Cross™.

OCR Textjunk That Is Probably a Valid Perl Program

Please don’t yell at me when you run it and find out it merge sorted your cat.

; 1 ^ 1*11111 « i i ai Willi i ii / i ' i . . I M
M h-'ii M f ■ " ' ," ' . ^ii' nr *! laii i i m io
n i ' - ^ ' ' ' ,S' ■' > .. . . / :VV '-' S. /■•■
'' - ■• ^ ."»"- ^ / i ^ ^ s ■ , i ;'^ '^ -■>:-f "
' ' • s« ' . ^ J ■ -^ , , - ..-' ( ' 1 ' ,"-. X ~
" ,. . ' ''■;- -•» , .- ^ >v- ; t " N-. ■T.'v \,'
,. ?., ,. '-. - - - < N-.-v- ... : i ■ ••' V V' s

The End of Consistency

In Safari on the Mac, single-clicking in anywhere in the location field will direct keyboard focus to the text area and place the cursor at the character boundary closest to where you clicked. This is the same behavior as every other text box in Mac OS X.

In Google Chrome, clicking text in the location field will automatically select the entire URL. Presumably this is because Google engineers feel that people are more likely to want to replace the entire URL than to edit a portion of it.¹

However, there are several scenarios where you’d be better off with Safari’s behavior: (1) there’s a typo in the URL you’d like to change; (2) you want to move up a level out of dead-end navigation by deleting everything after the last slash; (3) you want to copy only a portion of the URL, either (a) just the host portion, or (b) just the file name portion; (4) you want to append text to the end of the URL; (5) you get the idea …

Chrome’s behavior is flawed for two fundamental reasons. First, it breaks consistency with the rest of the Macintosh interface. You may not think it’d be a big deal, but it’s upsetting—often on a subconscious level—when someone expects a widget to behave a certain way and it responds slightly differently. Second, Chrome’s custom URL field favors beginner users at the expense of all others. While an application that tells a new user, “hey, I made your life easier by assuming you meant to select the entire URL,” may be helpful to the novice, it’s hostile to experts—they already know how URLs and text fields work, and their actions are usually intentional.²

The infuriating thing about the inconsistency is the conflicting responses to bug reports filed by users who found the behavior undesirable: Google has said both that the standard interface behavior is correct and we will follow suit and that the current, non-standard behavior is better. This run-around response seems typical of Google, a company that has little experience providing technical support for end users.