I’ve been thinking a bit about what Apple’s going to do as a followup for Tiger. Assuming that Apple sticks with an 18-month cycle for 10.5 (“Lion”?), then we’ll be getting our hands on it slightly before Longhorn’s release date. Given that, it’s pretty clear that Apple is already thinking about what they want in 10.5 so they can trump Microsoft’s Longhorn offerings in the media. More then any previous release of OS X, I expect this one to be flashy; if Tiger was really an attempt to revamp the developer core of OS X, then I expect 10.5 to focus on the user experience.
A few things that I expect to see:
Improved metadata support. Just like Jon Siracusa has been saying, metadata is important. With Spotlight, we now have a framework for searching and storing file metadata. With 10.5, I expect to see the ability to tag files with specific metadata tags, like project name, priority, status, and so on. This is a feature that was pulled from Longhorn because of time constraints; Apple should be able to jump way ahead of Windows without a lot of work in this area.
Networkable Spotlight. Right now, Spotlight only works on local filesystems. Adding network support for Spotlight searching (and all of the other metadata that goes with it) will finally give people a decent reason to buy OS X servers.
A Finder replacement. Once we have the new metadata engine, we’re going to need a UI for managing it. I’m not sure if Apple will simply provide us with “Finder 2.0,” or if they’ll produce a radical new file manager and then provide users with the ability to revert to the old finder if they don’t want to upgrade. Either way, if Apple finishes their metadata back-end, then the Finder really needs to be updated to match. Since Apple hasn’t really put much work into the Finder since 10.0, and there are boatloads of customer complaints about the current Finder, I think it’s time for it to get re-written from the ground up, with the new version centered around metadata and searching.
More syncing and disconnected support. Windows has supported disconnected operation on network shares for years. That way, you can have a network share for some project, but have Windows maintain a local cache so you can still edit documents while you’re on a plane or otherwise unable to connect to the network. It’s a great feature, and Apple doesn’t have anything even vaguely like this right now.
Full 64-bit support. With Tiger, Apple has some support building 64-bit applications, but you can’t use any of the UI frameworks from 64-bit apps. I fully expect 10.5 to provide equal support for all current APIs from 32- or 64-bit code, and I expect that Xcode will have simple support for building “fat” 32⁄64 applications. If Apple leaves 64-bit apps out in the cold, then they’re giving Microsoft a big opening, and we’ll see claims that OS X isn’t “a real 64-bit operating system.” By 2007, at least 80% of new PCs and Macs will come with 64-bit CPUs; even if most apps won’t need to support 64-bit address spaces, it’d be a major mistake not to give developers the tools that they need to build 64-bit apps.
Resolution-independant displays. Right now, most UI elements are sized in pixels; that works great when all monitors have roughly the same DPI, but it falls down horribly when displays range from 72 to 300 DPI. Switching from a 100 DPI display to a 200 DPI display currently means that all of your UI elements (menu bar, window decorations, icons) shrink to half of their current size. Tiger has the ability to change this hidden inside the developer tools, but most apps have a hard time dealing with it right now; by the time 10.5 rolls around, I expect the OS to automatically adjust the UI size based on the DPI of the output device; this will let us have HD-resolution displays on 15-inch PowerBooks without needing to ship a magnifying glass with every new laptop.