inconsequence

There have been two successful OS transformations on the desktop. One was Mac OS Classic to Mac OS X, which was implemented using virtualization. The other was DOS to Windows, which was a slightly weirder affair (initially, Windows was a DOS application, then Windows NT ran DOS under virtualization). You might argue Windows was a horrible kludge, but its more elegant step-sibling (OS/2) handled DOS compatibility by virtualization and failed miserably in the marketplace.

It seems pretty clear, especially given the power of current hardware, that virtualization is the way to handle an OS transformation. Indeed, many commentators have suggested that Microsoft should replace Windows with a brand new modern, lightweight OS, and manage compatibility by virtualization.

Right now, iPhone OS runs under Mac OS X via virtualization. Multitouch is not well-supported (for obvious reasons), but that’s simply a hardware issue (Macs don’t have touchscreens).

Of Apple’s two operating systems, one of generates over two-thirds of its revenue, and an even larger proportion of its profits. And that OS isn’t Mac OS X. Apple is notorious (I might say famous, but chose not to) for doing a lot with a little — there are probably fewer people working on Mac OS X right now than on Microsoft Word. But we haven’t even heard a whisper about Mac OS X 10.7.

So, the question is, whither Mac OS X?

Merging it with iPhone OS is impractical for numerous reasons, not least of which is that iPhone OS runs very lean and mean and Mac OS X conspicuously does not. A virtualization solution would allow iPhone OS to continue working beautifully on low-powered devices (by not providing the compatibility box) while allowing higher-powered devices to offer full backwards compatibility.

Of course, Apple already has an iPhone virtualization box for Mac OS X, so a “unification OS” could be released tomorrow if Apple wanted to make Mac OS X that OS, but I think a Tablet computer that boots instantly into iPhone OS and lets you run Mac OS X in a virtual box as needed is far more desirable than a Tablet computer that boots in 30s into Mac OS X and lets you run iPhone OS in a virtual box. Either would be pretty compelling, though.

The other question is, what benefits are there to keeping the two platforms separate? I would argue there are none. iPhone OS devices with a Mac compatibility box would, in essence, answer all the “closed platform” criticisms — the Mac platform is rich and open, and running it on a virtual machine would sandbox it from the managed world of iPhone. Indeed, virtualization affords Apple the option of opening iPhone OS devices without adding risk for users who don’t want it. The only real reason not to go down this route right now is hardware.

There’s your Mac App Store, by the way. It’s the App Store, and iPhone OS running on your Mac.

So, I predict that iPhone OS will subsume Mac OS X within three years. Obviously, it will long since have ceased being iPhone OS, of course. Hence, the title of this post.

While Snow Leopard isn’t being sold on its new features, it probably could be. Here’s an interesting snippet of Apple’s Snow Leopard pages that a post on Cheetah 3d’s forums put me onto:

Collada Digital Asset Exchange (.dae) files are a popular way to share 3D models and scenes between applications. Preview now displays these files with OpenGL-powered 3D graphics, so you can zoom and rotate around a 3D scene and play viewpoint animations. You can also print the scene or save it as an image or movie file. And you can use Quick Look to display them as well.

A quick Googling of “Snow Leopard Collada” reveals that this little announcement is creating quite a buzz, and not without reason.

What’s Collada? It’s a rich 3d file format that — like FBX and unlike 3DMF — doesn’t suck and — unlike FBX — isn’t proprietary and subject to bizarre incompatibility issues every time Autodesk squeezes out a new version of the SDK.

By “rich” I mean that it enables 3d programs to store almost any information they would store in their own proprietary formats. By “doesn’t suck” I mean that other programs are generally able to get that information out again.

If Apple’s support for Collada goes deeper than simply being able to render .dae files in Preview and QuickLook, e.g. allowing programmers to relatively easily load, retrieve data in usable form from, save, and render Collada files, it could lead to a renaissance of 3d on the Mac, and deliver the benefits that Quickdraw 3D promised and so spectacularly failed to deliver.

The second bit: “retrieve data in usable form from” is the tricky part, since Collada is a very hairy format, which means that an ideal implementation would support all the hairiness, but allow you to access raw data in a lowest-common denominator way — e.g. load in complex NURBS objects and then acquire them as meshes at a specified detail level. One thing Apple might do is pick which bits of Collada to support thoroughly and — if they pick well — effectively create a compatible subset of Collada which different software developers can depend on and treat as the defacto standard (kind of the way Photoshop 4.0′s file format is a defacto standard for interoperable Photoshop documents).

Apple’s support for Collada could also help give Collada the momentum it needs to gain stronger support in the 3d world. Right now, a lot of programs have so-so Collada support and superb FBX support (in large part because Autodesk makes supporting FBX pretty easy). But Collada is richer and less proprietary than FBX. In a sense, Collada is analogous to QuickTime in that it can serve as both a format for storing raw and working content as well as delivering optimized end-user content.

Supporting Collada at OS level could be a great “judo” move on Apple’s part. It would allow the Photoshop wannabes to easily offer Photoshop-like 3D support (easily embed 3d objects in layered documents, and provide texture-painting capabilities), and encourage everyone on the Mac — or interoperating with people using Macs — to support a single rich 3d file format. It creates an ecology where indie developers can create “do one thing and one thing well” 3d tools on the Mac that doesn’t really exist on any platform right now.

We’ll see.

Rixstep is one of the most intelligently critical Mac-centric (well, originally NeXT-centric) websites around. Here’s their latest commentary on Apple’s security issues — an issue they’ve been railing about for years.

Now, I’m not about to switch to Windows for the superior security of Vista (which, if anything, is more vulnerable to social engineering attacks, which are by far the biggest threat*), but it would be nice if Apple closed some of the glaring holes before there actually are some real world exploits.

Note: * all the remote attacks to which Mac OS X is vulnerable are in essence going to require a social engineering approach to work in the first place. Whether it’s getting a user to visit a web page with a specially crafted QuickTime movie, or getting a user to download a trojan, the point is getting the user to do something. Vista screws up its warnings by crying wolf so often that the chance of a user inadvertently clicking “yes” at a critical juncture is much higher, and this is something CanWest et al don’t measure.

Daringfireball has been linking to a number of opinion pieces about MacHeist lately, and it had me thinking. Opinions on MacHeist seem to fall into two camps: it’s a great deal for customers and a lousy deal for developers OR it’s a great deal for everyone. One obvious camp is unexplored: it’s a lousy deal for everyone except MacHeist.

In my opinion, there are three kinds of software that benefit from MacHeist: (1) stuff that would never have sold very many copies because it’s fundamentally a silly product, (2) stuff that’s actually surprisingly good but doesn’t get as many users as it should either because (i) the userbase doesn’t exist (e.g. not that many people really need it), or (ii) they’ve already bought something that obviates it, and (3) good, fairly successful software that’s about to receive a major upgrade.

Examples of the first kind (basically useless) include most of the stuff in every MacHeist bundle. E.g. iSale, Picturesque, SousChef.

Examples of the second kind (good but unknown or in a saturated market) this time around includes Acorn, Kinemac, Wiretap Studio, Espresso, and arguably World of Goo. (It’s also possible that Acorn and Kinemac are type 3, but I doubt it. Kinemac’s user forums have about ten posts in them, and Acorn seems to have been swamped by Pixelmator — and deservedly so.)

Examples of the third kind not in this bundle would be Cheetah 3D (which was in a bundle last year when the developer was hoping to have version 5 out within six months, although it’s still not out) and Unity Indie (which was in the same bundle just before v2 came out).

I don’t know enough about Phoneview and LittleSnapper to categorize them.

So the value proposition for customers is basically, look at the stuff in the list, figure out which ones you’d actually use and try to guess whether they’re about to receive costly upgrades. Then factor in the value of what you’re getting relative to the bundle price. Most customers probably vastly overestimate the use they’ll get out of the software in the bundle and buy a bunch of stuff that they never end up using. But, they feel good so no major harm done. And maybe they start using a package they’d never have found otherwise, so that’s cool.

The value proposition for developers is basically… am I getting anywhere with this product? If not, this is a win. If so, then do I think I can gain more exposure than I will (potentially) lose in license sales OR can I grab customers and make money off them with upgrades? If so, then this is a win. Otherwise I’m just screwing myself.

It seems to me that developers probably think longer and harder about this value proposition than customers do. At least they probably do now. Back when MacHeist first arrived on the scene, I think that the bundle was essentially a bad deal for (almost) everyone. By now, MacHeist is paying a scaling royalty (I believe) and developers know what the deal is and have made better decisions. So it’s only customers screwing themselves.

Caveat Emptor.

One of the most baffling gaps in Mac third-party software is programming-oriented text editors with autocomplete. Now, obviously there’s XCode, vim, and emacs (which, being free, are all something of a problem for would-be competitors), and a bunch of cross-platform tools like Eclipse and Komodo, but XCode is really oriented towards Cocoa development and is kind of like using Microsoft Word to edit a shopping list, while the others are all non-Mac-like (and kind of suck anyway).

The Mac heavyweight text-editing champs — BBEdit and TextMate — have many great features, but don’t do autocompletion very well or at all, respectively. (There’s some kind of third-party hack add on for TextMate, but you need to compile it yourself and few seem to be able to get it working.) A lot of Unity developers were using PCs or Virtual Windows boxes to run Visual Studio just because it has an autocompleting text editor that doesn’t suck — that’s how bad it was. (Now that Unity runs on Windows their lives have gotten much easier, which is a pretty sad statement.)

Before you scream at me about how, say, Subethaedit has some kind of autocomplete support, or mention Coda (which has OK autocomplete support) or Espresso (which may one day have halfway decent extensible autocomplete support but right now is a work-in-progress), go and try Visual Studio or, if you’re allergic to Windows how about Realbasic. Realbasic‘s built-in text editor has autocomplete that doesn’t suck, e.g. it recognizes context, knows about intrinsic language constructs as well as library functions and the stuff you’ve declared, and doesn’t incorrectly complete stuff you need to fix constantly or fail to offer “function” when I type in “fun” in a .js file.

I will say this: TextMate’s macro facility is truly awesome (you can type swi->TAB and get a switch statement template, and then tab through the bits you need to change, almost like a context-sensitive-in-place-dialog-box), if this were paired with a proper autocomplete system (like RealBasic’s) it would be the best I’ve seen and then some — maybe 2.0 will have this — but right now the situation on the Mac remains pretty dismal.