Solipsism Gradient

Just arrived at the hotel in San Francisco, trip was OK and uneventful, though of course tiring. The Internet connection is very flaky, but I’ll try to post regularly from here on. Stay tuned.

Well, since I last wrote, a reasonably definite version of Klicko has been published (1.1.1 build 207) and I deemed the supporting code to be mature enough to serve as basis for the next version of Quay. So, since then, I’ve been busy on that.

On June 4th I’ll be arriving in San Francisco – WWDC starts on June 8 – and hopefully by then I’ll have an early alpha version of Quay 1.2 (or maybe 2? II?), and of the Quay Plugin Developer Kit as well. Stay tuned.

At first I thought I wouldn’t make it, but now I’m very happy to announce that I’m going to WWDC 2009.

I’ll arrive in San Francisco around noon on June 4th (Thursday), and will leave, also around noon, on June 16th (Tuesday). I’ll be glad to meet with anyone who’s interested…

More as it happens!

One significant announcement (some say the only one) at WWDC is the Safari 3 Beta, which includes Safari for Windows; at least it’s the one I’ve seen the most varied interpretations of, so far.

Considered as a beta release, Safari 3 is so-so. The Mac version needs a reboot because it also substitutes the Dock (which runs Dashboard widgets) and the system-wide webkit. It also substitutes the standard Safari installations. I had to reinstall Flash afterwards to get some sites to work. For my usual sites, it performed quite well although I had one crash. I don’t have a XP machine to test the Windows version on, but I hear it’s unusable on non-English versions, and very flaky on most English systems as well.

Steve Jobs stated the primary intention was to widen Safari’s marketshare, and the demo concentrated on a supposed serious speed advantage on Windows – “more than twice as fast as Internet Explorer”. And then, in the “one last thing” section, he refers to a “very sweet solution” for developing apps for the iPhone : the full Safari engine, no SDK needed allows Web 2.0/AJAX applications. (The entire section was received with silence by the crowd.) Steve’s statement that this is “a very modern way to build applications” somewhat contradicts what he said at D5:

…I love Google Maps, use it on my computer, you know, in a browser. But when we were doing the iPhone, we thought, wouldn?t it be great to have maps on the iPhone? And so we called up Google and they?d done a few client apps in Java on some phones and they had an API that we worked with them a little on. And we ended up writing a client app for those APIs. They would provide the back-end service. And the app we were able to write, since we?re pretty reasonable at writing apps, blows away any Google Maps client. Just blows it away. Same set of data coming off the server, but the experience you have using it is unbelievable.

…

And you can?t do that stuff in a browser.

So people are figuring out how to do more in a browser, how to get a persistent state of things when you?re disconnected from a browser, how do you actually run apps locally using, you know, apps written in those technologies so they can be pretty transparent, whether you?re connected or not.

But it?s happening fairly slowly and there?s still a lot you can do with a rich client environment.

So here we have at least two apparent intentions: get more penetration in the global browser “market” (maybe “mindshare” would be a better term as they’re nearly all free for the end-user), and open up iPhone development for Windows owners. Both sound logical.

More market penetration would surely be good for Apple. As John Gruber notes, Apple gets income from the Google search bar – tens of millions of dollars per year isn’t bad. And having Safari available on Windows removes one lame excuse for webmasters that build sites that don’t render properly (or at all) on Safari; it’s no longer necessary to own a Mac for checking that out.

Speaking of rendering properly, Safari for Windows, or rather WebKit, includes the Lucida fonts and several low-level frameworks, among them CoreGraphics, ColorSync, ImageIO and CoreFoundation. Some people believe this is a first step towards reviving the Yellow Box for Windows idea, but Cocoa is much larger than that… Safari is just a relatively thin shell around WebKit, and the Windows version shows no signs of being written in Objective-C, for one. Of course many people are once more complaining that Safari for Windows renders fonts differently. Joel Spolksy explains:

Apple and Microsoft have always disagreed in how to display fonts on computer displays. Today, both companies are using sub-pixel rendering to coax sharper-looking fonts out of typical low resolution screens. Where they differ is in philosophy.

– Apple generally believes that the goal of the algorithm should be to preserve the design of the typeface as much as possible, even at the cost of a little bit of blurriness.

– Microsoft generally believes that the shape of each letter should be hammered into pixel boundaries to prevent blur and improve readability, even at the cost of not being true to the typeface.

I’ve talked to several people about this issue. Beyond the expected bias of familiarity – everyone is used to their main working platform and finds the other’s rendering strange – I found that most graphic artists and font designers prefer the Mac rendering, while most web designers and IT people seem to prefer the Windows rendering.

But beyond that, the fact that Safari for Windows tries to reproduce exactly the Mac rendering is important (and not a bug, as many Windows users are claiming). I’ve seen this myself on my site; tweaking font size etc. so the page looks good on the Mac often produces quite different layout when you view it on a Windows browser, and it’s impossible to get it to look exactly the same, down to line breaks and text heights. This is doubly important when you’re viewing the page on a small screen like the iPhone has. Zooming the page display like the iPhone does seems to mandate the Apple rendering engine: Windows’ pixel alignment is counterproductive there.

Coming back to the “zero-cost iPhone (non)SDK” idea. Reactions in the developer community seem fairly mixed. At WWDC itself, of course, most developers aren’t web app developers, but were looking forward to doing Cocoa on the iPhone. And of course that implies that everybody thought that, when Apple would come out with an iPhone SDK (or even a generic OS X SDK, as I thought before the conference) Cocoa/OS X developers would have a monopoly… after all, they already own the development hardware and software. Nobody seriously believed that Apple would invest in doing a separate iPhone SDK that would include a simulator or even a compiler for one of the existing Windows IDEs, as Palm used to do when their products were still 68K-based (no idea what they do today).

Instead, so “real” Mac developers think, every newbie with a few weeks JavaScript under their belt are now free to declare themselves “iPhone developers”. It’s the same thing that happened with typographers when the original Mac 128K came out, and what will happen with animators when the final Leopard will come out – look for the equivalent of tags or impenetrable DVD menus in most of the new iPhone and Leopard apps. We’ll be pretty sick of moving GUI elements soon, and there’s no hope of standardizing web apps anyway. It’s the millennium of the amateurs… head for the hills!

Well, while I think some of it will be that bad – just as ransom-note typography was in the 80s, and garish pages assaulted us in the 90s (and still do, come to think of it), it’s won’t be all that bad. Apple will have new category for its Design Awards and there will be some cool, well-designed apps out. Let Darwin take care of the rest.

OK, here’s what I wrote a few days ago, regarding the Mac OS X transition to Intel:
Rainer Brockerhoff wrote:

…Most Cocoa developers that didn’t call Carbon frameworks to any great extent, or that didn’t have to deal with complex binary files, were able to recompile their apps into the Universal (“fat binary”) format in a few hours or days. In contrast, most developers of Carbon apps of any complexity faced months or years of conversion.

I invited comments on Apple’s carbon-dev mailing list, and some people objected to the paragraph quoted above. In particular, Apple engineer Eric Albert wrote:

I’d probably moved more Mac OS X code to Intel than anyone else before the announcement — some of the iApps and a bunch of other apps, plus a ton of work in the OS — and of the code I’d worked on, the Cocoa apps happened to take more work than the Carbon ones. That was really nothing more than coincidence because the Carbon apps I was working on dealt with structured data better than the Cocoa ones, but there’s nothing inherently more complex about the Intel transition for Carbon than there is for Cocoa. Mathematica, which is most assuredly a complex Carbon app, took four hours to get up and running on Intel, faster than any other app I’ve seen.

The primary reason for some Carbon apps taking a long time to move to Intel was that they weren’t using Mach-O or Xcode at the time the transition was announced and both were required for Intel support.

Carbon apps already using Mach-O and Xcode came over to Intel fairly easily.

Well, that’s quite definite; I was wrong there. I was wondering why, though, and here’s what I found: the RDF is to blame…

Here’s what Steve Jobs said at the WWDC 2005 keynote, where I was physically present, and quite near the front too:

So, let’s take a look at this again: Widgets, Scripts and Java just work. Cocoa apps, literally a few days and your Cocoa app’s going to be running with an Intel version. Carbon apps, it’s to be a few weeks, a few more tweaks, although there are exceptions to that although we maybe overstating it here, which we’ll see in a minute. And and in Metrowerks we don’t know, you’ve got to get to Xcode. So the key here is getting to Xcode.

And I distinctly remember the same point being made later in the reserved “state of the union” sessions: click a checkbox in Xcode, “boom” for Cocoa… not that easy with Carbon.

There it is then. I don’t have any Carbon apps myself, and didn’t have to migrate anything from Metrowerks CodeWarrior either, so I thought Carbon was to blame for stuff like the Adobe Photoshop delay. I’ll update my original post below; thanks to everybody who sent in comments.

It’s over and reactions have been coming in from everywhere. Many people were, to put it mildly, disappointed. So how did I do?

Hardware: I said “not likely but hoped-for”. No hardware announcement, and the stock fell about $4 as soon as this became apparent – the webstore was down, but apparently just for a general style makeover.

“OS X” SDK and consolidation: nothing, so no hardware development kit either. This is actually what I’m most disappointed about. No mention of OS X at all, as far as I could make out.

Leopard beta release on the ADC site: Steve said it’d be for attendees only but very few people heard exactly what he said. I still hope it’ll be out next week.

Apps included: little was mentioned, some changes are on the website now.

New Finder and desktop: well, not new, but a facelift. At least I got that one right, but it was very predictable.

ZFS: not mentioned. Blame Jonathan Schwartz.

Virtualization: none. I really hoped they’d have switching between Leopard and Boot Camp in the same way that Fast User Switching works. Instead, it seems they took the easy way out. You can set Mac OS X to “safe sleep”, boot into Windows, set that to “hibernate”, then switch back and forth without rebooting either. I wonder how long that takes – 10 to 15 seconds would be quite acceptable, I think.

.mac: it still lives, and the “back to your Mac” feature looks interesting. No Google, though.

So, even though I didn’t get many things right, it’s not too bad either. Let’s wait and see what trickles out from the real (read: developer) part of the conference. That said, the new Finder and UI stuff doesn’t look too shabby, and I’m still positive that on the developer side this is a very significant release. More as it happens…

Tomorrow WWDC begins and as usual there are many rumors and few certainties. I didn’t make it this year, unfortunately.

Of course possible ideas have been flying fast and furious, but as usual nobody else knows for sure what sort of new Steve Jobs will present at the Monday keynote. Still, here are my ideas about what might happen, or at least about what I wish might happen.

WWDC being a developer’s conference, it’s not usual for it to see new hardware released – the iSight, the Mac Pro and of course the Intel migration being notable exceptions. Still, I think that new iMacs and/or new displays aren’t completely unlikely to be a by-the-way item in the keynote, or perhaps might be announced a few weeks later. Certainly both lines have gone too long without an upgrade; personally I’d like to see new displays and iMacs sharing a front bezel; the iMac’s “chin” is certainly avoidable by now, and it would mean that the iMacs would be distinguished from the same-sized displays only by a deeper rear casing. Having iSight cameras in the displays would of course be a given.

Some people feel that we’ll see a new iPod and/or a new tablet/ultrathin MacBook line – there’ll certainly be no iPhone hardware announcements. I think this unlikely, except in the context of…

…OS X without a “Mac” in front of it. Yes, I do have hopes of seeing a generic “OS X” SDK; Leopard will either be OS X or we’ll have explanations of how Mac OS X and OS X relate. Currently we have a multi-layer OS with several distinct APIs that developers can code to, but they all ultimately are seen in a single GUI layer – the one formerly known as Aqua – and run on a unified hardware platform (the Mac). Possibly, from now on, we’ll also be able to code to several hardware platforms and several GUI surfaces; neither iPods nor iPhones will ever sprout mice and keyboards, and it will be years before desktops and laptops will be accessible from multitouch only. (Though it would be cool to have optional multitouch sensors on those hypothetical new iMacs and displays…) And, before I forget it, there’s also the simplified – in fact, iPod-like – interface on the TV, which would be yet another GUI surface to reckon with.

Of course to have a generic OS X SDK we’ll need development hardware to test stuff on. If it’s unsafe to let developers code directly for the iPhone, as Apple has repeatedly said, some sort of touch tablet might even be a viable development system. I suppose this mostly depends on larger screens/panels being available, and thinner screens and mainboards. Some of Apple’s recent patents point in that direction; the one about glueing together structural casings, for instance.

On the general software front, Apple is of course making an effort to put people into a position to code cool new stuff for when Leopard comes out in about 4 months. Hopefully this will extend to releasing the “final” beta of Leopard during or very soon after WWDC; keeping it overly secret would now be unproductive. So, all that stuff like resolution independence and core animation will hopefully be used by the new apps. Speaking of apps, some people are of course viewing Leopard mostly as a vehicle to see incremental improvements to Mail, Safari, iChat and so forth – a distinctly unexciting way of seeing in my opinion. I’m not really that interested in the apps that will come included in Leopard except as examples in using all the cool new APIs.

An exception is the Finder, the app that even for most developers is the “face” of the OS. Much wailing and gnashing of teeth has ensued when the past Leopard seeds showed a scarcely changed Finder; I do think (and hope) that we’ll see a reasonable facelift to it during the keynote, though perhaps a completely new Finder might be too much to hope for.

I’m reasonably sure that we’ll have ZFS as a formatting option for external hard drives, and it would certainly be neat if this option meshed somehow with Time Machine for more reliable/expandable backups, but I’m not informed enough about the technical aspects of that. I don’t think booting from ZFS is likely, especially after the recent leaking of that possibility by some folks at Sun – let’s just hope Steve Jobs doesn’t cancel it outright just to prove them wrong!

Virtualization, after being discarded months ago as an option, is suddenly rumored to be in the works again. The options seem to be: a Parallels workalike built into Leopard (unlikely), Apple buys Parallels outright (also unlikely), simply releases a final version of Boot Camp (a little more likely but utterly boring), or – the one I think possible, and have mentioned here before – Apple will build a virtual machine hypervisor into the firmware, running OS X and whatever Boot camp supports in multiple virtual screens.

The final item of interest is .mac. There’s an SDK for that and everybody, up to and including Steve Jobs, agrees that .mac is underpowered and behind the times. In the last few days it’s become more likely that the increasing collaboration between Apple and Google would extend to Google taking .mac under their wing. They certainly have more server power to do it; in my tests, .mac has always been so slow in Brazil as to be unusable.

So, that’s it for now. More after the keynote…

Leopard is delayed for 4 months – until October. John Gruber has a good analysis, as does Daniel Jalkut.

A couple of weeks ago I wrote:
Rainer Brockerhoff wrote:

Even so, people who have not seen anything of Leopard beyond some leaked screenshots wrote excitedly about a MacWorld release, then about a March release, then when their wild predictions aren’t confirmed start to moan that “Apple’s been having trouble getting Leopard out” and now, even, that “Leopard had reportedly been delayed until October”. I really hope that Apple will show more details before WWDC, but I won’t be too surprised if they don’t.

The reference was to this DigiTimes story, which I didn’t even want to link to at the time because it sounded so absurd. Well, looks like they got it right, although the excuse for the delay is the iPhone, not Boot Camp. Although this is not stopping some people arguing that one of things apple will do during the extra months is converting Boot Camp into a Parallels-style virtualizer – something I’d previously described as likely to be implemented in firmware, until they took the TPM out of newer Intel Macs.

In retrospect, it’s not too surprising. Unusually, Apple is releasing 3 major products this year – TV, iPhone and Leopard – and all run some form of OS X despite having very different target markets and form factors. (Also unusually for Apple, all 3 were pre-announced.) So far, only the iPhone hasn’t been delayed, and clearly Apple felt that delaying all 3 would be a serious PR loss. Ergo, putting people to work on the iPhone makes some sense, supposing Apple managed to avoid the mythical man-month effect.

It’s still difficult to assess what this means for the upcoming WWDC. Sure, a feature-complete build will be available there, but unless something revolutionary new thing is revealed, it may not have much impact. Launching the iPhone there won’t be a big thing for developers unless a SDK is announced. I won’t be able to go this, so it seems I won’t miss much…