Mac OS X Lion - John Siracusa's Ars Technica Review

Mac OS X 10.7 Lion: the Ars Technica review 04/01/12 19:03

Mac OS X 10.7 Lion: the Ars Technica review
Mac OS X 10.7 was first shown to the public in October 2010. The presentation was
understated, especially compared to the bold rhetoric that accompanied the launches
of the iPhone ("Apple reinvents the phone") and the iPad ("a magical and revolution-
ary device at an unbelievable price"). Instead, Steve Jobs simply called the new oper-
ating system "a sneak peek at where we're going with Mac OS X."

Behind Jobs, the screen listed the seven previous major releases of Mac OS X:
Cheetah, Puma, Jaguar, Panther, Tiger, Leopard, and Snow Leopard. Such brief retro-
spectives are de rigueur at major Mac OS X announcements, but long-time Apple
watchers might have felt a slight tingle this time. The public "big cat" branding for
Mac OS X only began with Jaguar; code names for the two earlier versions were not
well known outside the developer community and were certainly not part of Apple's
official marketing message for those releases. Why bring the cat theme back to the
forefront now?

The answer came on the next slide. The next major release of Mac OS X would be
called Lion. Jobs didn't make a big deal out of it; Lion's just another big cat name,
right? Within seconds, we were on to the next slide, where Jobs was pitching the new
release's message: not "king of the jungle" or "the biggest big cat," but the "back to the
Mac" theme underlying the entire event. Mac OS X had spawned iOS, and now Ap-
ple was bringing innovations from its mobile operating system back to Mac OS X.

Apple had good reason to shy away from presenting Lion as the pinnacle that its
name implies. The last two major releases of Mac OS X were both profoundly shaped
by the meteoric rise of their younger sibling, iOS.

http://arstechnica.com/apple/reviews/2011/07/mac-os-x-10-7.ars Page 1 of 106


Steve Jobs presents the first seven releases of Mac OS X in a slightly unusual for-
mat

Leopard arrived later than expected, and in the same year that the iPhone was intro-
duced. Its successor, Snow Leopard, famously arrived with no new features, concen-
trating instead on internal enhancements and bug fixes. Despite plausible official ex-
planations, it was hard to shake the feeling that Apple's burgeoning mobile platform
was stealing resources—not to mention the spotlight—from the Mac.

In this context, the name Lion starts to take on darker connotations. At the very least,
it seems like the end of the big cat branding—after all, where can you go after Lion?
Is this process of taking the best from iOS and bringing it back to the Mac platform
just the first phase of a complete assimilation? Is Lion the end of the line for Mac OS
X itself?

Let's put aside the pessimistic prognostication for now and consider Lion as a prod-
uct, not a portent. Apple pegs Lion at 250+ new features, which doesn't quite match
the 300 touted for Leopard, but I guess it all depends on what you consider a "fea-
ture" (and what that "+" is supposed to mean). Still, this is the most significant release
of Mac OS X in many years—perhaps the most significant release ever. Though the
number of new APIs introduced in Lion may fall short of the landmark Tiger and
Leopard releases, the most important changes in Lion are radical accelerations of past



trends. Apple appears tired of dragging people kicking and screaming into the fu-
ture; with Lion, it has simply decided to leave without us.

Table of Contents

Installation
Reconsidering fundamentals
Lion's new look
Scroll bars
Window resizing
Animation
Here's to the crazy ones
Window management
Application management
Document model
Process model
The pitch
The reality
Internals
Security
Sandboxing
Privilege separation
Automatic Reference Counting
Enter (and exit) garbage collection
Cocoa memory management
Enter ARC
ARC versus garbage collection
ARC versus the world
The state of the file system
What's wrong with HFS+
File system changes in Lion
File system future
Document revisions
Resolution independence
Applications
The Finder



Mail
Safari
Grab bag
System Preferences
Auto-correction
Mobile Time Machine
Lock screen
Emoji
Terminal
About This Mac
Recommendations
Conclusion

A brief note on branding: on Apple's website and in some—but not all—marketing materials,
Apple refers to its new Mac operating system as "OS X Lion." This may well turn out to be
the name going forward, but given the current state of confusion and my own stubborn nos-
talgia, I'm going to call it "Mac OS X" throughout this review. Indulge me.

Installation

Lion's system requirements don't differ much from Snow Leopard's. You still need an
Intel-based Mac, though this time it must also be 64-bit. The last 32-bit Intel Mac was
discontinued in August of 2007; Apple chose a similar four-year cut-off for dropping
PowerPC support, with minimal customer backlash. Time marches on.

But sometimes time marches on a bit too fast. Though this is the second version of
Mac OS X that doesn't support PowerPC processors, this is the first version that won't
run PowerPC applications. In Snow Leopard, the Rosetta translation engine allowed
PowerPC applications to run, and run well, often faster than they ran on the (admit-
tedly older) PowerPC Macs for which they were developed. Lion no longer includes
Rosetta, even as an optional install.

No one expects eternal support for PowerPC software, and any developer that does-
n't yet have Intel-native versions of all its applications is clearly not particularly dedi-
cated to the Mac platform. Nevertheless, people still rely on some PowerPC applica-
tions. For example, I have an old PowerPC version of Photoshop. Though Photoshop
has long since gone Intel-native, it's an expensive upgrade for someone like me who
uses the program only rarely. The PowerPC version suits my needs just fine, but it


uses the program only rarely. The PowerPC version suits my needs just fine, but it
won't run at all in Lion.

Another common example is Quicken 2007, still the most capable Mac version of In-
tuit's finance software, and still PowerPC-only. This is clearly Intuit's fault, not Ap-
ple's, but from a regular user's perspective, it's hard to understand why Apple would
remove an existing, completed feature that helped so many people.

In reality, every feature has some associated maintenance cost. This is perhaps even
more true of a binary translation framework that may have deep hooks into the oper-
ating system. I'm willing to give Apple the benefit of the doubt and assume that dis-
entangling PowerPC-related code from the operating system once and for all was im-
portant enough to justify the customer inconvenience. But it still stings a little.

The future shock continues with the purchase and installation process. Lion is the
first version of Mac OS X to be distributed through Apple's recently introduced Mac
App Store. In fact, the Mac App Store is the only place where you can buy Lion.

Apple's decision last year to sell its iLife and iWork applications through the Mac
App Store was not unexpected, but the presence of Apple's professional photography
application, Aperture, caught some people off guard—as did its greatly reduced
price ($80 vs. $200 for the boxed version).

The developer preview releases of Lion were also distributed through the Mac App
Store. Apple's developer releases have been distributed digitally for many years now,
but the switch from downloading disk images from Apple's developer website to "re-
deeming" promo codes and downloading new builds from the Mac App Store raised
some eyebrows. When Apple announced that its new Final Cut Pro X professional
video editing application would—you guessed it—be distributed through the Mac
App Store, and at a greatly reduced price, even the most dense Apple watchers start-
ed to get the hint.

And so we have Lion, priced at a mere $29 (the same as its "no new features" prede-
cessor), available exclusively through the Mac App Store. It's an audacious move,
yes, but not unexpected.

Apple is so done with stamping bits onto plastic discs, putting the discs into card-
board boxes, putting those boxes onto trucks, planes, and boats, and shipping them
all over the world to retail stores or to mail-order resellers who will eventually put



those same boxes onto a different set of trucks, trains, and planes for final delivery to
customers, who will then remove the disc, throw away the cardboard, and instruct
their computers to extract the bits. No, from here on out, it's digital distribution all
the way. (This, I suppose, marks the end of my longstanding tradition of showing the
product boxes or optical discs that Mac OS X ships on. Instead, you can see the in-
staller application icon on the right.)

Lion is a large download and fast network connections are still not ubiquitous. But
new Macs will come with Lion, so the most relevant question is, how many people
who plan to upgrade an existing Mac to Lion don't have a fast network connection?
The class of people who perform OS upgrades probably has a higher penetration of
high-speed Internet access than the general population. I also suspect that Apple re-
tail stores may be willing to help out customers who just can't manage to download a
3.76GB installer in a reasonable amount of time.

[Update: Macworld reports that there will, in fact, be a physical manifestation of
Lion. Starting in August, Apple will sell Lion on a USB stick for $69. Apple has also
said that customers are welcome to bring their Macs to Apple retail stores for help
buying and installing Lion.]

In the meantime, if you're reading this, chances are good that you have a fast broad-
band connection; feel free to stop reading right now, launch the Mac App Store, and
start your multi-gigabyte download before continuing. What you'll be rewarded with
at the end is an icon in your Applications folder labeled "Install Mac OS X Lion."
(See?)

Once you have the installer application, you could (were you so inclined) dig into it
(control-click, then Show Package Contents) and find the meaty center, a 3.74GB disk
image (InstallESD.dmg, stored in the Contents/SharedSupport folder). You
could then use that disk image to, say, burn a Lion installation DVD or create an
emergency external boot disk.

I doubt any of these things are officially supported by Apple, but the point is that
there's nothing exotic about the Lion installer. Like all past versions of Mac OS X,
Lion has no serial number, no product activation, and no DRM of any kind. In fact,
the Mac App Store's licensing policy is even more permissive than past releases of
Mac OS X. Here's an excerpt from Lion's license agreement:



If you obtained a license for the Apple Software from the Mac App Store,
then subject to the terms and conditions of this License and as permitted by
the Mac App Store Usage Rules set forth in the App Store Terms and Con-
ditions (http://www.apple.com/legal/itunes/ww/) ("Usage Rules"), you
are granted a limited, non-transferable, non-exclusive license:

(i) to download, install, use and run for personal, non-commercial use, one
(1) copy of the Apple Software directly on each Apple-branded computer
running Mac OS X Snow Leopard or Mac OS X Snow Leopard Server ("Mac
Computer") that you own or control;

The references to Snow Leopard are a bit confusing, but keep in mind that you need
Snow Leopard to purchase and download Lion for the first time. I suspect the license
agreement will be updated once Lion has been out for a while.

There's also another interesting clause in the license, from that same section:

(iii) to install, use and run up to two (2) additional copies or instances of the
Apple Software within virtual operating system environments on each Mac
Computer you own or control that is already running the Apple Software.

Putting it all together, Apple says you're allowed to run up to three copies of Lion—
one real, two inside virtual machines—on every Mac that you own, all for the low,
low price of $29. Not a bad deal.

The installer itself is dead simple, foreshadowing the pervasive simplification in Ap-
ple's new OS. There are no optional installs and no customization. The only response
the user provides is agreeing to the obligatory EULA, and the only configurable in-
stall parameter is the target disk.



But wait a second—how exactly is this going to work? Surely an entirely new operat-
ing system can't be installed on top of the currently running operating system by an
application stored on the same volume. Without a plastic disc to boot from, how is it
even possible to upgrade a standalone Mac with just one hard drive?

These questions probably won't occur to an average consumer, which is sort of the
point, I guess. Sure enough, if you just close your eyes, launch the installer applica-
tion, and click your way through the handful of screens it presents, your Mac will re-
boot into what looks like the standard Mac OS X installer application from years past.
When it's done, your Mac will reboot into Lion. Magic!

Okay, it's not magic, but it is a bit complicated. The first and most lasting surprise is
that the Lion installer will actually repartition the disk, carving out a 650MB slice of
the disk for its own use.

Don't worry, all existing data on the disk will be preserved. (Mac OS X has had the


ability to add partitions to existing disks without destroying any data for many years
now.) All that's required is enough free space to reshuffle the data as needed to make
room for the new partition.

Here's an example from my testing. I started with a single 250GB hard drive split into
two equal partitions: the first named "Lion Ex," currently running Snow Leopard, and
the intended target of the Lion install, and the second named "Timex," the Time Ma-
chine backup volume for Lion Ex. The output from the diskutil list command
appears below.

/dev/disk1
#: TYPE NAME SIZE
IDENTIFIER
0: GUID_partition_scheme *250.1
GB disk1
1: EFI 209.7
MB disk1s1
2: Apple_HFS Lion Ex 125.0
GB disk1s2
3: Apple_HFS Timex 124.6
GB disk1s3

Now here's that same disk after installing Lion, with the new partition highlighted:

/dev/disk1
#: TYPE NAME SIZE
IDENTIFIER
0: GUID_partition_scheme *250.1
GB disk1
1: EFI 209.7
MB disk1s1
2: Apple_HFS Lion Ex 124.5
GB disk1s2
3: Apple_Boot Recovery HD 654.6
MB disk1s3
4: Apple_HFS Timex 124.6
GB disk1s4



The new partition is actually considered a different type: Apple_Boot. The Recovery
HD volume won't be automatically mounted upon boot and therefore won't appear
in the Finder. It's not even visible in the Disk Utility application, appearing only as a
tiny blank space in the partition map for the disk. But as shown above, the command-
line diskutil program can see it. Diskutil can mount it too.

Doing so reveals the partition as a normal HFS+ volume. The top level contains a di-
rectory named com.apple.recovery.boot which in turn contains a few small
files related to booting along with an invisible 430MB internally compressed disk im-
age file named BaseSystem.dmg. Mount that disk image and you find a 1.52GB
bootable Mac OS X volume containing Safari, most of the contents of the standard
/Applications/Utilities folder (Disk Utility, Startup Disk, Terminal, etc.), plus
a Mac OS X Lion installer application. In other words, it looks a lot like a standard
Mac OS X installer DVD.

A subset of the files copied to the recovery partition is also copied to the installation
target disk by the installer and blessed as the new bootable system. This is what the
Lion installer reboots into. The files to install will be read from the Lion installer ap-
plication downloaded earlier from the Mac App Store. After the installation is com-
plete, the temporary boot files are removed, but the Recovery HD partition remains
on the disk. Hold down ⌘R during system startup to automatically boot into the Re-
covery HD partition. (Holding down the option key during startup—not a new fea-
ture in Lion—will also show the Recovery HD partition as one of the boot volume
choices.)

Booting from the recovery partition really means mounting and then booting from
the BaseSystem.dmg disk image on the recovery partition. Doing so presents a list
of the traditional Mac OS X install disc options, including restoring from a Time Ma-
chine backup, reinstalling Mac OS X, running Disk Utility, resetting your password,
and so on. There's also an option to get help online, which will launch Safari. Includ-
ing Safari on the recovery partition is a nice touch, since most people's first stop when
diagnosing a problem is Google, not the Genius Bar.

The upshot is that after all the file compression magic added in Snow Leopard to re-
duce the footprint of the OS, Lion steals over half a gigabyte of your disk space as
part of its installation process, and never gives it back. The partition's name makes
Apple's intent clear: it's meant as a last-ditch mechanism to diagnose and repair a


Mac with a hosed boot volume. (Hosed, that is, in the software sense; existing as it
does on the boot disk itself, the recovery partition won't be much use if the disk has
hardware problems.)

Apparently Apple has decided that the ability to boot a Mac into a known-good (soft-
ware) state is well worth sacrificing a small amount of disk space. MacBook Air own-
ers or other Mac users with diminutive solid-state disk drives may disagree, howev-
er. In that case, the disk space can be reclaimed by some judicious repartitioning with
Disk Utility (or the diskutil command-line tool) while booted from another disk.
But don't be surprised when the fellow at the Genius Bar frowns a little at your devia-
tion from the Apple Way.

Reconsidering fundamentals

The user-visible changes in Lion are legion. You'll be hard-pressed to find any part of
the user interface that remains completely unchanged from Snow Leopard, from the
look and feel all the way down to basic behaviors like application and document
management. In Lion, Apple has taken a hard look at the assumptions underlying the
last ten years of Mac OS X's development—and has decided that a lot of them need to
change. Get ready.

Lion's new look

Let's ease into things with a tour of Lion's revised user interface graphics. Though
Apple still uses the name "Aqua" to refer to Lion's interface, the look is a far cry from
the lickable, candy-coated appearance that launched the brand. If you can imagine
three dials labeled "color," "contrast," and "contour," Apple has been turning them
down slowly for years. Lion accelerates that process.



Hover to swap: Standard controls in Lion and Snow Leopard

The shapes have started to change, too. The traditional capsule shape of the standard
button has given way to a squared-off, Chiclets-style appearance. The tubular shape
of the progress bars, a fixture since even before the dawn of Mac OS X, has been re-
placed with a vaguely puffy stripe of material. Radio buttons, checkboxes, slider
thumbs, segmented controls, "tab" controls—nearly everything that used to protrude
from the screen now looks as if it was pounded down with a rubber hammer.

Even the elements that look identical, like the plain gray window title bars, are slight-
ly different from their Snow Leopard counterparts. The new look is not a radical de-
parture—everything hasn't gone jet black and grown fur, for example—but this is the
first time that nearly every element of the standard GUI has been changed in a way
that's identifiable without a color meter or a magnifying glass.

For the most part, the new look speaks in a softer voice than its predecessor. The total
removal of blue highlights from several controls (e.g., pop-up menus, combo boxes,
slider thumbs, and tab controls) makes most interfaces appear slightly less garish. On
the other hand, the additional green in the blue highlights that still do exist makes
those controls appear more saccharine.

Apple says that its goal with the Lion user interface was to highlight content by de-
emphasizing the surrounding user interface elements. You can see this most clearly


emphasizing the surrounding user interface elements. You can see this most clearly
in sidebar and toolbar icons, which are now monochromatic in most of the important
bundled applications. But this has the unfortunate side effect of making interface ele-
ments less distinguishable from each other, especially at the small sizes typical in
sidebars. I'm not sure the "increased emphasis on content" is enough to balance out
the loss, especially in applications like the Finder.

Appearance changes can have effects beyond emphasis, fashion, and mood. Take the
"traffic light" red, yellow, and green window widgets, for example. As you can see in
the images on the right, they've gotten smaller in Lion. Or rather, the colored portion
has gotten smaller; the actual clickable area has lost only one pixel in height and five
pixels in total width across all three widgets.

But the psychological effect of the shrunken appearance is something else entirely.
Despite the tiny difference in the functional size, I find myself being ever-so-slightly
more careful when targeting these widgets in Lion. It's a little annoying, especially
since it's not clear to me how the new, smaller size fits into Lion's new look. Does
such a small reduction in size really serve to better emphasize window content? After
all, none of the other controls have gotten any smaller.

Other aspects of the new look have clearer intentions. The flatter, more matte look of
most controls, and especially the squared-off shape of the standard button, all bring
to mind the look of Apple's other operating system, iOS. One control in particular
takes the iOS connection even further.

Finally, there's Apple's budding love affair with a particular linen texture. It made its
first appearance on the backside of some Dashboard widgets. More recently, it was
used as the background pattern for the notifications sheet in iOS 5. In Lion, it's fea-
tured even more prominently as the background for the newly restyled login screen,
now featuring circular frames for user icons. (Also note the subset of menu bar status
icons still visible in the top-right corner of the screen.)



Linen for your login screen

Scroll bars

Scroll bars, which Apple likes to call "scrollers" these days, are among the least-
changed interface elements in Mac OS X. While the rest of the Aqua interface was re-
fined—edges sharpened, pinstripes removed, shines flattened—scrollbars stubbornly
retained their original Aqua look for over a decade.

A scroll bar from Mac OS X DP3, released in 2000

A scroll bar from Mac OS X 10.6, released in 2009

Scroll bars haven't been entirely static in Mac OS X, however. For many years, iTunes
has had its own custom scroll bar look.

A scroll bar from iTunes 10.2.2, released in 2011

When these new scroll bars were first introduced in iTunes 7 in 2006, there was some
speculation that this was a trial run for a new look that would soon spread through-
out the OS. That didn't happen. But now, five years later, scroll bars are finally chang-
ing system-wide in Mac OS X. Here's a scroll bar from Lion:


ing system-wide in Mac OS X. Here's a scroll bar from Lion:

A scroll bar from Mac OS X 10.7 Lion

The smeared gradient and fuzzy edges of the iTunes scroll thumb are nowhere to be
seen. Instead, we have a narrow, monochrome, sharp-edged lozenge. Just like the
window widgets, the scroll thumb appears slightly smaller than its Snow Leopard
counterpart. (In this case, total scroll bar width and the clickable area are actually the
same as in Snow Leopard.)

The change in appearance might distract you from what's really different: where are
the scroll arrows? You know, the little buttons on either end of the scroll bar (or
grouped together on one end) that you click to move the scroll thumb a bit at a time?
Well, they're gone.

But wait, there's more. Here's a Finder window.

The complete contents of Lion's Applications folder…or is it?

Though I can assure you that Lion comes with more than eight applications, you
wouldn't know it from looking at this screenshot. Forget about the arrows, where are
the scroll bars?

Placing the cursor into the window and using the scroll wheel on the mouse or two-
finger scrolling on a trackpad reveals what you might have already guessed based on
the shape and appearance of the new scroll thumbs. Extremely thin, monochrome
scroll thumbs fade in as the scrolling begins, and disappear shortly after it ends.


These transient scroll thumbs appear on top of the window's content, not in alleys re-
served for them on the edges of the window.

Initiating scrolling (via mouse wheel or trackpad) reveals overlay scroll bars. More
applications below!

These ghostly overlay scroll bars are straight out of iOS. When they were introduced
in 2007 on the iPhone's 3.5-inch screen, they made perfect sense. Dedicating one or
more finger-width strips of the screen for always-visible, touch-draggable scroll bars
would have been a colossal waste of pixels (and anything less than a finger's width of
pixels would have been too narrow to comfortably use). Overlay scroll bars were es-
sential in iOS, and completely in keeping with its direct manipulation theme. In iOS,
you don't manipulate an on-screen control to scroll, you simply grab the whole
screen with your finger and move it.

Apple isn't (yet) asking us to start poking our fingers at our Mac's screen, but it does
now ship every Mac with some kind of touch-based input device: internal trackpads
on laptops, and external trackpads or touch-sensitive mice on desktops. Lion further
cements the dominance of touch by making all touch-based scrolling work like it
does on a touchscreen. Touching your finger to a control surface and moving it
downwards will move the document downwards, revealing more content at top and
hiding some of the content that was previously visible on the bottom. This sounds
perfectly logical, but it also happens to be exactly the opposite how scrolling has tra-
ditionally worked with mouse scroll wheels. The effect is extremely disconcerting, as
our fingers unconsciously flick at the scroll-wheel while our eyes see the document


moving the "wrong" way.

Scroll direction setting in the Mouse preference pane. Checked means the new
Lion scrolling direction is in effect.

Thankfully, there is a preference to restore the old mapping of finger movement to
scroll direction. There's a second setting in the Trackpad preference pane, phrased in
the opposite way. Unfortunately, the settings are linked; you can't have different val-
ues for each kind of input device.

Though the unification of scrolling gestures is logical, it's difficult to get used to after
so many years of doing things the other way. The most common scrolling direction is
downwards, and the most natural finger movement is curling inwards. These two
things align when using a mouse wheel with the "old" scrolling direction setting. Old
habits aside, it may be that the difference between touching a screen directly and
touching a separate device on a horizontal surface in front of the screen is just too
great to justify a single input vocabulary.

Either way, there's sure to be an uncomfortable transition period for everyone. For
example, the two-finger swipe to the left or right used to switch between screens in
Launchpad (described later) feels "backwards" when the scroll direction preference is
set to the traditional, pre-Lion behavior. Perhaps just seeing a screen covered with a
grid of icons unconsciously triggers the "iOS expectations" region of our brains. (And
if you set the scroll direction to "feel right" for two-finger swiping in Launchpad, then
the four-finger swipe between Spaces feels backwards! Sigh.)

Scroll bars do more than just let us scroll. First, their state tells us whether there's any-
thing more to see. A window with "inactive" (usually shown as dimmed) scroll bars
indicates that there is no content beyond what is currently visible in the window. Sec-
ond, when a document has more content than can fit in a window, the scroll bars tell
us our current position within that document. Finally, the size of the scroll thumb it-
self—or the amount of room the scroll thumb has to move within the scroll bar, if you
want to look at it that way—gives some hint about the total size of the content.

Most computer users aren't conscious of such subtleties, but their combined effects
are profound. Long-time Mac users might remember a time when scroll thumbs were
perfectly square regardless of the total size of a window's content. When I think back
to my time using those scroll bars, I don't recall any problems. But just try using these


to my time using those scroll bars, I don't recall any problems. But just try using these
so-called "non-proportional" scroll bars today. The modern computer user's mind re-
volts at the lack of information, usually treating it instead as misleading information
about the total size of a window's content. ("This window looked like it had pages
and pages of content, but when I dragged the tiny square scroll thumb all the way
from the top to the bottom, it only revealed two new lines of text!") Only when this
cue is gone do you realize how much you've been relying on it.

And keep in mind that proportional scroll thumbs are the most subtle of the cues that
scroll bars provide. The others are even more widely relied upon. The complete lack
of visible scroll bars leaves a huge information void.

Let's put aside the familiar for a moment. In the absence of scroll bars, are there other
visual cues that could provide the same information? Well, if truncated content ap-
pears at the edge of a window, it's usually a safe bet that there's more content in that
direction. The prevalence of whitespace (between icons in the Finder, between lines
of text, etc.) can make such truncation less obvious or even undetectable, but at least
it's something. For total content size and position within the document, there's no al-
ternative even that good.

But fear not, gentle scroller. Like the scroll direction, scroll bar visibility has a dedicat-
ed preference (in the General preference pane):

Scroll bar settings in the General preference pane

The default setting, "Automatically based on input type," will use overlay scroll bars
as long as there's at least one touch-capable input device attached (though the track-
pad on laptops doesn't count if any other external pointing devices are connected). If
you don't like this kind of second-guessing, just choose one of the other options. The
"When scrolling" option means always use overlay scroll bars, and the "Always" op-
tion means always show scroll bars, using the appearance shown earlier.

Lion includes new APIs for briefly "flashing" the overlay scroll bars (i.e., showing
them, then fading them out). Most applications included with Lion briefly show the
scroll bars for windows that have just appeared on the screen, have just been resized,
or have just scrolled to a new position (e.g., when showing the next match while
searching within a document). This helps soften the blow of the missing information
previously provided by always-visible scroll bars, but only a little.



Applications with other UI elements whose correct placement relies on the existence
of a reserved 16-pixel stripe for the scroll bar outside the content area of the window
may be forced to display what Apple calls "legacy" scroll bars. (Apple's term for non-
overlay scroll bars tells you all you need to know about which way the wind is blow-
ing on this issue.) You can see an example of one such UI element in the image on the
right. The document scale pop-up menu (currently showing "100%") pushes the hori-
zontal scroll bar to the left to make room for itself. Clearly, this will not work if the
scroll bar overlays the content area and is hidden most of the time. Apple suggests
that such applications find new homes for these interface elements, at which point
the AppKit framework in Lion will allow them to display overlay scroll bars.

Lion's scroll bars are a microcosm of Apple's new philosophy for Mac OS X. This is
definitely a case of reconsidering a fundamental part of the operating system—one
that hasn't changed this radically in decades, if ever. It's also nearly a straight port
from iOS, which is in keeping with Apple's professed "back to the Mac" mission. But
most importantly, it's a concrete example of Apple's newfound dedication to simplici-
ty.

In particular, this change reveals the tremendous weight that Apple gives to visual
simplicity. A complete lack of visible scroll bars certainly does make the average Mac
OS X screen look a lot less busy. A lack of visual clutter has been a hallmark of Ap-
ple's hardware and software design for years, and iOS has only accelerated this
theme. Also, practically speaking, the sum of all those 16-pixel-wide stripes reserved
for scroll bars on window edges may add up to a nontrivial increase in the number of
pixels available for displaying content on a Mac's screen.

But there is a price to be paid for this simplicity; one person's noise is another person-
's essential source of information. Visual information, like the size and position of a
scroll thumb, is one of the most efficient ways to communicate with humans. (Com-
pare with, say, numeric readouts showing document dimensions and the current po-
sition as a percentage.)

These sacrifices were an essential part of the iPhone's success. The iPad, though larg-
er, is clearly part of the same touch-based family of products, and is wisely built on
the same foundation. But the Mac is a different kettle of fish—and not just because
the screen sizes involved may be vastly larger, making the space savings of hidden
scroll bars much less important.


The Mac user interface, with its menus, radio buttons, checkboxes, windows, title
bars, and yes, scroll bars, is built on an entirely different interactivity model than iOS.
The Mac UI was built for a pixel-accurate indirect pointing device; iOS was built for
direct manipulation with one or more fingers. The visual similarity of on-screen ele-
ments and the technical feasibility of porting them from one OS to the other should
not blind us to these essential differences.

It's interesting that all of the scrolling changes in Lion have preferences that allow
them to be reverted to their pre-Lion behaviors. The defaults clearly indicate the di-
rection that Apple wants to go, but the settings to reverse them—public, with real
GUIs, rather than undocumented plist hacks—suggest caution, or perhaps even some
internal strife surrounding these features.

Such caution is well-founded. Hidden scroll bars in particular have trade-offs that
change dramatically based on the size of the screen and the input device being used.
Like many features in Lion, the scrolling changes are most useful and appropriate on
the Macs that are closest to iOS devices in terms of size and input method (the 11-
inch MacBook Air being the best example). But on a Mac Pro with dual 27"
2560x1440-pixel displays attached, Lion's scrolling defaults make far less sense.

Window resizing

A lack of traditional scroll bars also means the elimination of the small patch of pixels
in the lower-right corner of a window where the vertical and horizontal scroll bars
meet. Since 1984, this area has been home to the one and only control used to resize a
window. Setting the scroll bar appearance preference to "always visible" restores the
clickable real estate, albeit sans the traditional "grip lines."

Despite the plain appearance, this resize control works as expected; what's unexpect-
ed is the cursor change that accompanies the action. The double-arrow cursor has
been used in other operating systems for years, mostly to differentiate two-axis resiz-
ing (width and height) from single-axis resizing (height only or width only). When
there's only one resize control per window, it's obvious that it can be used to change
both the width and the height. Lion's new cursor can mean only one thing…



Window resizing from all edges (composite image)

That's right, long-suffering switchers, Lion finally allows windows to be resized from
any edge and from all four corners, with a special cursor for each of the eight starting
points. (When a window is at its size limit, the cursors show an arrow pointing in a
single direction—a nice touch.)

As you can see from the image above, what Apple hasn't done is add borders to the
windows. So where, exactly, do we "grab" when resizing from a borderless window
edge? There's no way around it: some pixels must be sacrificed to the gods of Fitts's
law.

A few pixels within the outer edge of the content area of the window (two to three,
depending on where you count from) are commandeered for window resizing pur-
poses. You can still click on these areas, and the click event will correctly propagate
to the application that owns the window, but you'll be clicking with a resize cursor
instead of a normal arrow cursor.

Two to three pixels doesn't make for a very wide target, however, which is why Ap-
ple has chosen to appropriate pixels from both sides of the window border. Four to


ple has chosen to appropriate pixels from both sides of the window border. Four to
five pixels outside the content area of the window are also clickable for window resiz-
ing purposes. Clicks in these areas don't get sent to the window (they're out of the
window's bounds) and they don't get sent to whatever happens to be behind the ac-
tive window—you know, the thing that you ostensibly just clicked on. Effectively,
Lion windows have thin, invisible borders around them used only for resizing. (Un-
like Mac OS 8 and 9 windows, which had real, visible borders, Lion windows can't be
dragged by their borders.)

When overlay scroll bars are in use, the full 16x16 pixel home of the traditional resize
widget in the lower-right corner is clickable, making this still the easiest target for
window resizing, whether it's visible or not.

Lion has a few more surprises on window edges, one of which is window size-relat-
ed. Windows belonging to applications that support Lion's new full-screen mode
may show an embossed double arrow icon on the far-right side of their title bars.
Clicking it will cause the window to fill the entire screen. Other windows, the Dock,
and even the menu bar are hidden in this mode. The window's title bar also disap-
pears, making it unclear how to exit this mode. But just stab the cursor at the top of
the screen and the menu bar slides back down into view, containing all the expected
menus plus a reversed version of the double arrow symbol. Click the inward-facing
arrows to take the current window out of full-screen mode.

Animation

Mac OS X has always used animation in its user interface, starting with the genie ef-
fect over a decade ago, and really ramping up with the introduction of the Core Ani-
mation framework three years ago. Lion continues this trend. In nearly all new or
changed applications in Lion, if something conceivable can be animated, it is. The
Finder is a good example. Even features whose functionality hasn't actually changed
in Lion, such as dragging multiple items from one window to another, are given a
fresh coating of animation and fades.

At its best, animation explicitly communicates information that was either absent or
only implied before. For example, the genie animation tells the user where a window
goes when it's minimized. In other cases, such as the water ripple effect in
Dashboard, animation can add a bit of fun to an interface.

But danger lurks. A newly discovered animation might delight the user the first time


But danger lurks. A newly discovered animation might delight the user the first time
it's shown, but the 350th time might not seem quite so magical. This is especially true
if the animation adds a delay to the task, and if that task is done frequently as part of
a time-sensitive overall task. The Dashboard water ripple is acceptable because
adding a new widget to the screen is an infrequent task. But if the screen rippled
every single time a new window appeared anywhere in the OS, users would revolt.

Well, guess what happens every time a new window appears on the screen in Lion?
No, it's nothing as garish as a water ripple, but there is an animation. Each window
starts as a tiny dot centered on the window's eventual position on the screen, then
quickly animates to its full size.

You get a window! You get a window! Everybody gets a window!

This animation conveys no new information. It does not tell the user where a window
came from, since the animation starts at the final position of the window. Whether or
not the animation actually delays the opening of the window, it certainly feels like it
does, which is even more important. This type of animation can make Lion feel slow-
er than Snow Leopard. And when an animation like this stutters or skips a few
frames due to heavy disk i/o or CPU usage, it makes your whole Mac feel slower,
like you're playing a 3D game with an inadequate video card. And for what? For
what someone at Apple hopes will be a lasting feeling of delight?

Perhaps it could be argued that the animation catches the eye more than a window
that appears instantly (though that probably depends on the size of the window and
what's behind it on the screen). For "unexpected" windows like error dialog boxes,
that could be a benefit. But for "expected" windows (i.e., those that appear in re-
sponse to deliberate user input), the powerful, primordial pull of these moving im-
ages is an unwelcome distraction, not a benefit.

It's conceivable that this animation could delight some users, but I have a hard time
believing that the enjoyment will last much past the first week. (Interestingly, this an-
imation does not play in reverse when a window is closed. This, perversely, makes
window closing feel faster than window opening in Lion.)

Unlike the scrolling behaviors discussed earlier, there are no user-visible preferences
for these new animations, which makes it all the more important for Apple to strike a
good balance. In my estimation, Lion crosses the line in a few places; the new win-
dow animation is the most egregious example. I look forward to discovering a way to


dow animation is the most egregious example. I look forward to discovering a way to

disable it. [Update: here it is: defaults write NSGlobalDomain NSAutomat‐
icWindowAnimationsEnabled -bool NO]

Here's to the crazy ones

Bruce Tognazzini, founder of the Apple Human Interface Group and 14-year Apple
veteran (1978-1992), is best known as the man behind the publication of the Apple
Human Interface Guidelines. In 1992, he published a book of his own: Tog on Inter-
face. Most of the examples in the book were taken from his work at Apple. Here's an
excerpt from pages 156-157:

Natural objects have different perceivable characteristics, among which
people can easily discriminate. Take the bristlecone pine. The oldest living
thing on earth, it has been formed and shaped by the wind and scarred by
thousands of years of existence. The youngest school kids look at it and
know there must be a lot of wind around there. They know the pine may
be even older than their father. They also know, to a certainty, that it is a
tree.

Kristee Kreitman Rosendahl, responsible for not only the graphic design of
HyperCard, but also much of its spirit, created a collection of Home icons
that shipped with the product.

No one has ever shown confusion at seeing various little houses on various
cards. Never once has someone turned around and said, "Gee, this little
house has three windows and seems to be a Cape Cod. Will that take me to
a different Home card than that two-story bunk house back in the other
section?" People are designed to handle multiplexed meanings gracefully,
without conscious thought.

In System 7, we multiplexed the meaning of system extensions, by develop-
ing a characteristic "generic" extension look, to which developers can add
their own unique look for their specific product. As the "bandwidth" of the
interface increases, these kinds of multiplexings will become more and
more practical.

This is Tog, godfather of the old-school Apple Human Interface Guidelines, stating
emphatically that interface elements do not have to look exactly the same in order for


emphatically that interface elements do not have to look exactly the same in order for

their function to be discerned. In fact, in the final sentence, Tog predicts that in-
creased computing power will lead to more diverse representations. The increased
"bandwidth" of user interfaces that Tog wrote about almost 20 years ago has now
come to pass, and then some.

Examples of "multiplexed meanings" in Mac OS X are not hard to find. Look at the
Dock, which has changed appearance several times during the history of Mac OS X
while still remaining immediately identifiable. And, as discussed earlier, nearly every
standard GUI control has changed its appearance in Lion. As Tog notes, people are
excellent at discarding unimportant details and focusing on the most salient aspects
of an item's appearance.

Now, keeping all this in mind, I invite you to gaze upon this screenshot of the version
of iCal that ships with Lion.

A stitch in time saves…something, presumably

When this change was first revealed in the second developer preview of Lion, there
was much gnashing of teeth. But ask yourself, is the function of every control in the
toolbar clear? Or rather, is it any less clear than it would be if iCal used the standard
Mac OS X toolbar appearance?


Mac OS X toolbar appearance?
The immediate, visceral negative reaction to the rich Corinthian leather appearance
had little to do with usability. What it came down to—what first impressions like
these always seem to come down to—is whether or not you think it's ugly. People
will take "really cool-looking but slightly harder to use" over "usable but ugly" any
day.

But there's something much more important than the change in appearance going on
here. Lion's iCal doesn't look different in an arbitrary way; it's been changed with
purpose. After the initial stitched-leather shock wore off, Apple watchers everywhere
leapt on the new iCal's deeper sin: its skeuomorphic design. From Wikipedia (empha-
sis added):

A skeuomorph is a derivative object that retains ornamental design cues to
a structure that was necessary in the original. Skeuomorphs may be delib-
erately employed to make the new look comfortably old and familiar,
such as copper cladding on zinc pennies or computer printed postage with
circular town name and cancellation lines. An alternative definition is "an
element of design or structure that serves little or no purpose in the arti-
fact fashioned from the new material but was essential to the object
made from the original material."

Apple has been down this road before, most notably with the QuickTime 4.0 player
application which included bright ideas like a "dial" control for adjusting the volume.
Dials work great in the real, physical world, and are certainly familiar to most people.
But a dial control in the context of a 2D mouse-driven GUI is incongruous and awk-
ward at best, and completely incomprehensible at worst.

The brushed metal appearance of the QuickTime player would later inspire an offi-
cially supported Mac OS X window appearance starting in version 10.2, only to be
dropped completely five years later in 10.5's grand interface unification. Now, three
years after that, the pendulum is swinging in the other direction again—and hard.

In the case of iCal, Apple has aped the appearance of an analogous physical object (a
tear-off paper calendar) but retained the behavior of standard Mac OS X controls.
This avoids the problems of the QuickTime 4.0 player's dial control, but it's far from a
clean win.

The trouble is, the new iCal looks so much like a familiar physical object that it's easy


The trouble is, the new iCal looks so much like a familiar physical object that it's easy
to start expecting it to behave like one as well. For example, iCal tries very hard to
sell the tear-off paper calendar illusion, with the stitched binding, the tiny remains of
already-removed sheets, and even a page curl animation when advancing through
the months. But can you grab the corner of a page with your mouse and tear it off?
Nope, you have to use the arrow buttons or a keyboard command, just like in the pre-
vious version of iCal. Can you scribble in the margins? Can you cross off days with a
pen? Can you riffle through the pages? No, no, and no.

At the same time, iCal is still constrained by some of the limitations of its physical
counterpart. A paper calendar must choose a single way to break up the days in the
year. Usually, each page contains a month, but there's no reason for a virtual calendar
to be limited in the same way. When dealing with events that span months, it's much
more convenient to view time as a continuous stream of weeks or days. This is espe-
cially true on large desktop monitors, where zooming the iCal window to full screen
doesn't show any more days but just makes the days in the current month larger.

The new version of Address Book in Lion is an even more egregious example.



These graphics are writing checks this interface can't cash

Address Book goes so far in the direction of imitating a physical analog that it starts
to impair the identification of standard controls. The window widgets, for example,
are so integrated into the design that they're easy to overlook. And as in iCal, the
amazing detail of the appearance implies functionality that doesn't exist. Pages can't
be turned by dragging, and even if they could, the number of pages on either side of
the spine never changes. The window can't be closed like a book, either. That red
bookmark can't be pulled up or down or removed. (Clicking it actually turns the
page backwards to reveal the list of groups. Did you guess that?) The three-pane
view (groups → people → detail) is gone, presumably because a book can't show
three pages at once. Within each paper "page" sits, essentially, an excerpt from the
user interface of the previous version of Address Book. It's a mixed metaphor that
sends mixed signals.

These newly redesigned Mac OS X applications are clearly inspired by their iOS
counterparts, which bear similar graphical flourishes and skeuomorphic design ele-
ments. (Address Book in particular is a dead ringer for the Contacts app on the iPad.)
In iOS, the inability to turn pages with the flick of a finger or yank out that tantalizing
red bookmark is even more frustrating. In both environments, when the behaviors
seemingly promised by the graphical design aren't delivered, all this artwork that
was so clearly labored over fades into the background. The application trains us to
ignore it. What was once, at best, a momentary amusement is reduced to visual noise.

In 2011, we're far past the point where computer interfaces need to reference their
forebearers in the physical world in order to be understandable (though it's possible
Apple thinks the familiarity of such designs is still an effective way to reduce intimi-
dation, especially for novice users). At the same time, hardware and software have
advanced to the point where there's now ample "bandwidth" (to use Tog's term) to
support visual and functional nuances beyond the bare necessities.

Interface designers are faced with the challenge of how best to use the glut of re-
sources now at their disposal. As Lion's iCal and Address Book applications demon-
strate, an alternate description of this situation might be "enough rope to hang your-
self."

Window management

Over the years, Apple has added several features that could loosely be defined as


Over the years, Apple has added several features that could loosely be defined as
"window management aids." The first, and arguably most successful, was Exposé, in-
troduced in Panther back in 2003. Two years later, Tiger shipped with Dashboard,
which provided a dedicated screen for small "widget" windows, keeping them off the
main screen. In 2007, Leopard brought official support for virtual desktops to Mac OS
X under the name Spaces.

Each of these features came with its own set of configurable keyboard shortcuts, hot
screen corners, and (eventually) multi-touch gestures. While each was understand-
able and useful in isolation, it was up to each user to figure out how best to incorpo-
rate them into a workflow. In Lion, Apple has taken a stab at consolidation under the
umbrella name of Mission Control. Each individual feature still exists, albeit in slight-
ly more limited forms, but activating one thing now provides access to them all.

Using any one of the supported Mission Control activation methods—a keyboard
shortcut, a hot screen corner, or a four-finger upwards swipe—causes the current
desktop picture to recede slightly into the center of the screen, revealing behind it our
old friend the linen pattern. Overlaid on this are groups of windows, badged by the
icons of the applications to which they belong. Along the top of the screen sit all open
Spaces. (In Lion, each full-screen window creates a new Space, so those windows ap-
pear at the top rather than grouped with the other windows from the same applica-
tion.) Dashboard is also (optionally) given its own Space.



Mission Control: Exposé + Spaces + Dashboard

A surprising number of things can be done from this screen. As with Exposé, clicking
on any window will bring it to the front. Windows can also be dragged into any of
the available Spaces (excluding Dashboard and those that contain a single full-screen
window). Moving the cursor (or dragging a window) to the upper-right corner of the
screen causes a panel with a "+" character to appear; clicking this creates a new space.
Holding down the option key makes Dashboard-style "close" widgets appear on any
non-fullscreen-window Spaces (except the original Desktop Space, which can never
be closed).

The biggest limitation of this new arrangement is that Spaces are now confined to a
one-dimensional line of virtual desktops. Four-finger swiping between spaces feels
great, but there's no wrap-around when you hit the end.

As big a step down as this is from the much more flexible grid arrangement of Spaces
in earlier versions of Mac OS X, the new limitations are probably a good idea. The
new behavior of full-screen windows and the surprisingly natural-feeling four-finger
swipes used to switch between them and enter Mission Control means that many
more Mac users will likely find themselves using these new features than ever used


more Mac users will likely find themselves using these new features than ever used

the combination of Exposé and Spaces in earlier versions of the OS. A simple line of
spaces with no wrap-around provides a safe, understandable environment for all
these new Spaces users.

For the experts, well, consolidation always has its price. In this case, as in many oth-
ers, Apple has decided that the good of the many outweighs the good of the few.

Application management

For all its warts, the radical simplification of application management brought to Mac
OS X by the Dock really has benefitted the platform. As I wrote in my ten year Mac
OS X retrospective, "For every user who continues to be frustrated by the Dock's limi-
tations, there are thousands of others who are buoyed in their computing efforts by
its reassuring simplicity and undemanding design."

But the Dock falls short, especially for novice users, as an application launcher. Or
rather, it falls short if the application to be launched isn't actually in the Dock. Most
novice users I know want to have every application they are likely to use available in
the Dock at all times. As these users gain experience, the Dock can become a very
crowded place. But why are these increasingly Mac-savvy users stuffing their Docks
to the gills rather than limiting its contents to just the applications they use most fre-
quently?

The answer lies in how applications not in the Dock are located and launched. Choic-
es include the Finder, Spotlight, or (I suppose) a Terminal window. Moving from an
always-visible line of colorful icons that's front and center on the screen to any one of
those alternatives represents a huge increase in conceptual and mechanical complexi-
ty.

If you don't understand how typing the name of an application into a search box can
be so much more difficult than clicking an icon in the Dock, I suggest that you have
not spent enough time with novice users. Such users often don't even know the name
of the application they want—or if they do, they don't know how to spell it. That's be-
fore considering the frequent disorientation caused by the rapid-fire search results re-
finement animation in the Spotlight menu, or the existence of multiple files whose
contents or names contain the string being searched for. And this all assumes novices
know (or remember) what Spotlight is and how to activate it in the first place.



The jump in complexity from the Dock to the Finder, I think, needs less explanation.
As a general rule, novice users just don't understand the file system. They don't un-
derstand the hierarchy of machines, devices, and volumes; they don't grasp the con-
cept of the current working directory; they don't know how to identify a file or fold-
er's position within the hierarchy. Fear of the file system practically defines novice
users; it is usually the last and biggest hurdle in the journey from timid experimenta-
tion to basic technical competence.

To put it another way, your dad can't find it if it's not in the Dock. (Well, my dad
can't, anyway. Sorry to all the Mac-savvy dads out there; I am one, after all.)

In Lion, Apple aims to fill that gap with an application launching interface that's
meant to be as easy to use as the Dock while providing access to every application on
the system. It's called Launchpad, and you'll be forgiven for thinking that it looks like
yet another interface element shamelessly ported from iOS.

Launchpad: iOS’s SpringBoard on your Mac

Launchpad can be activated with a Dock icon (which, importantly, is in the Lion
Dock by default), a multitouch gesture (a somewhat awkward pinch with the thumb


Dock by default), a multitouch gesture (a somewhat awkward pinch with the thumb
and three fingers), or by dragging the mouse cursor to a designated corner of the
screen. The grid of application icons that appears doesn't just look like iOS's Spring-
Board, it also behaves like it, right down to the "folders" created by dragging icons on
top of each other.

Holding down the option key makes all the icons sprout close widgets as they start to
wiggle. Swiping right and left on the touchpad or with a click and drag of the mouse
will move from screen to screen, accompanied by a familiar iOS-like dotted page in-
dicator.

Launchpad will find applications in the standard /Applications folder as well as
~/Applications (i.e., a folder named "Applications" in your home directory), and
any subfolders within them. Applications in the ~/Downloads folder or on the desk-
top are not detected, which may actually be a problem for Mac users who have not
yet figured out how to perform drag-and-drop application installations—yet another
area where the Mac App Store will help make things simpler.

Speaking of which, when purchasing an application in the version of the Mac App
Store that ships with Lion, the application icon leaps out of the Mac App Store win-
dow and lands in the next available position in the Launchpad grid, with an iOS-like
progress bar overlaid on the new application's icon. If the Launchpad icon is in the


progress bar overlaid on the new application's icon. If the Launchpad icon is in the

Dock, it displays a similar progress bar and the icon bounces once when the down-
load finishes.

Both serve as examples of animation that conveys useful information. "Here's where
the application you just purchased has 'landed' on your Mac," the animation says. "To
find it again, click the icon that just bounced in your Dock."

Given the wealth of excellent third-party application launchers available for the Mac,
I'm not sure there's any reason for an expert user to use Launchpad instead of their
current favorite alternative. But unlike, say, the Dock, Launchpad is easily ignored.
Turn off the gesture, deactivate the hot corner, and remove the icon from the Dock
and you'll never have to see it.

For everyone else, however, Launchpad will provide a huge improvement in usabili-
ty. Even expert users should be excited about its arrival because it should make tele-
phone or e-mail-based family technical support a bit easier.

Document model

Lion introduces what Apple calls, with characteristic conviction, a "modernized" doc-
ument model. I'm inclined to agree with this word choice. Like so many other aspects
of Lion, document management is attempting to shed its legacy baggage—and there's
plenty to shed. The conventions governing the interaction between users, applica-
tions, and documents have not changed much since the personal computer became
popular in the early 1980s.

Apple first attempted a minor revolution in this area with OpenDoc in the 1990s. In-
stead of launching an application in order to create a document, OpenDoc promised
a world where the user would open a document and then work on it using an inter-
changeable set of components created by multiple vendors. In other words, OpenDoc
was document-centric rather than application-centric.

The changes in OpenDoc promised to radically shift the balance of power in the ap-
plication software market. But powerful software companies like Microsoft and
Adobe were not particularly motivated to break their popular, full-featured applica-
tions into smaller components that customers could mix and match with components
from other vendors. At the time OpenDoc was released, Apple was nearing the nadir
of its popularity and influence in the industry. Predictably, OpenDoc died on the


of its popularity and influence in the industry. Predictably, OpenDoc died on the

vine.

Fast-forward to today, where a much more powerful and confident Apple takes an-
other crack at the same area. The most pressing problem, today's Apple has decided,
is not the interaction between application code and document data, but rather the in-
teraction between the user and the computer.

Despite decades of public exposure to personal computers, human expectations and
habits have stubbornly refused to align with the traditional model of creating, open-
ing, and saving documents. The tales of woe have become clichés:

The student who writes for an hour without saving and loses everything when
the application crashes.
The businessman who accidentally saves over the "good" version of a document,
then takes it upon himself to independently reinvent version control—poorly—
by compulsively saving each new revision of every document under slightly dif-
ferent names.
The Mac power user who reflexively selects the "Don't Save" button for one doc-
ument after another when quitting an application with many open windows,
only to accidentally lose the one document that actually had important changes.
The father who swears he saved the important document, but can't, for the life
of him, remember where it is or what he called it.

At this point, we can no longer call this a problem of education. We've tried educa-
tion for years upon years; children have been born and grown to adulthood in the PC
era. And yet even the geekiest among us have lost data, time, or both due to a "stu-
pid" mistake related to creating, opening, and saving documents.

And so Apple's decree in Lion is as it was on the original Macintosh in 1984, and as it
is on iOS today: the machine must serve the human, not the other way around. To
that end, Apple has added APIs in Lion that, when used properly, enable the follow-
ing experience.

The user does not have to remember to save documents. All work is automati-
cally saved.
Closing a document or quitting an application does not require the user to make
decisions about unsaved changes.


The user does not have to remember to save document changes before causing
the document's file to be read by another application (e.g., attaching an open
document with unsaved changes to an e-mail).
Quitting an application, logging out, or restarting the computer does not mean
that all open documents and windows have to be manually re-opened next time.

Earlier versions of Mac OS X supported a form of automatic saving. If you had an
open TextEdit document with unsaved changes, TextEdit would (eventually) save a
backup copy of the file with the text " (Autosaved)" appended to the file name. If the
application crashed or the Mac lost power, you could retrieve (some of) your un-
saved changes by finding the autosaved file and opening it.

Lion introduces a variant of this practice: autosave in place. Rather than creating a
new file alongside the original, Lion continuously saves changes directly to the open
document. It does this when there are large document changes, during idle times, or
on demand in response to requests from other applications for access to the docu-
ment's data.

For all of this to work, applications must be updated to use the new APIs. In particu-
lar, a new File Coordination framework must be used in order for an application to
notify another that it wants to access a document that's currently open. The applica-
tion that has the document open will then trigger an autosave to disk before allowing
the requesting application to reference the document's data. Attaching a document to
an e-mail or using Quick Look in the Finder are two examples of when this might
happen.

At this point, a little bit of "geek panic" might be setting in. For those of us who un-
derstand the pre-Lion document model and have been using it for decades, the idea
that we are no longer in control of when changes to open documents are saved to
disk seems insane! What if I accidentally delete a huge swath of text from a document
and then Lion decides to autosave immediately afterwards?

Not every change is meant to be saved, after all. The practice of speculatively making
radical changes to a document with the comfort of knowing that none of those
changes are permanent until we hit ⌘S is something experienced Mac users take for
granted and may be loath to give up.

I confess, I omitted one item from the list of changes enabled by Lion's modern docu-


ment model. Here it is:

The user does not have to manually manage multiple copies of document files in
order to retrieve old versions.

If you still don't get it, check out the item in the File menu formerly known as "Save."
It now reads "Save a Version" instead. Every time a Lion-savvy application autosaves
a document, it stores a copy of the previous version before it overwrites the file with
the new data. A pop-up menu in the title bar of each document window provides ac-
cess to previous versions.

A menu in the title bar provides access to previous versions of a file

Select the "Browse All Versions…" menu item to enter a Time Machine-like space-
themed screen showing all previous versions of the file. Using this interface, the doc-
ument can be reverted to any earlier version, or snippets of data from earlier versions
may be copied and pasted into the current version. Though the star field background
and surrounding timeline interface are provided automatically, the document win-
dows themselves are actual windows within the application. They can be scrolled
and manipulated in any way allowed by the application, though the contents of pre-
vious versions may not be modified.



Document version browser…in spaaaaace!

The standard Cocoa document framework will manage many of the details for appli-
cation developers, including automatically purging very old versions of files. The
document versioning interface shown above is also integrated with Time Machine,
showing both locally stored file versions and older versions that only exist on the
Time Machine backup volume. Going forwards or backwards in the document time-
line is accompanied by a neat star-field "warp" animation.

Restoring the document to an earlier state actually just pushes a duplicate of that
state to the front of the stack of all changes. In other words, restoring a document to
its state as of an hour ago does not discard all the changes that happened during that
hour.

Returning to the title bar pop-up menu, the "Revert to Last Saved Version" menu
item returns the document to its last explicitly saved state (i.e., what it looked like the
last time the user typed ⌘S or selected the "Save a Version" menu item). "Duplicate"
will create a new document containing the same data as the current document. Final-
ly, the "Lock" item will prevent any further changes to the document until it is explic-
itly unlocked by the user. Documents will also automatically be locked if they're not


itly unlocked by the user. Documents will also automatically be locked if they're not

modified for a little while. The auto-lock time is configurable in the "Options…"
screen of the Time Machine preference pane (of all places), with values from one day
to one year. The default is two weeks.

The auto-lock delay setting, cleverly hidden in the Time Machine preference pane

There is no graphical interface to previous versions of documents outside of an appli-
cation. Previous versions can't be viewed or restored from within the Finder, for ex-
ample. Forcing all version manipulation to be within the application is limiting, but it
also neatly solves the problem of how to present document contents with full fidelity
—beyond what Quick Look offers—when looking at past revisions.

One unexpected implication of autosave is that it makes quitting applications much
less painful. If you've ever had to quickly log out or shut down a Mac that has been
up and working hard for weeks or months, you know how awful it is to have to
wade through umpteen dialog boxes, each demanding a decision about unsaved
changes before allowing you to continue.

These are not easy questions, especially for files that may have been open for a long
time. Put aside deciding whether the changes are worth saving; can you even remem-
ber what the unsaved changes are? Were they intentional, or did you accidentally
lean on the keyboard and delete a selected item some time last week? Now multiply
this dilemma by the number of open documents with unsaved changes—and imag-
ine you're in a hurry. It's not a pleasant experience.

Autosave eliminates these hassles. Quitting an application that supports autosave
happens instantly, with no additional user input required—always.

Of course, by quitting an application (or quitting all applications by logging out or
restarting) you're also losing all of your accumulated state: all your open documents,
the size and position of their windows, scroll positions, selection state. Losing state
can prove even more painful than playing "20 questions" with a swarm of "unsaved


can prove even more painful than playing "20 questions" with a swarm of "unsaved

changes" dialog boxes. Assuming you can remember what documents you had open,
can you find them again?

Lion offers new APIs to address this problem as well. A suite of new state
encoding/decoding hooks allow Lion applications to save and restore any and all as-
pects of document state. Upon relaunch, an application is expected to restore all the
documents open when it was last quit, with all their state preserved.

So, how's that "geek panic" now? Still there, huh? Well, let me try to reassure you. As
a committed user of a great Mac text editor that, years ago, implemented its own ver-
sion of almost all the document management features described so far, I can tell you
that you get used to it very quickly. Spoiled by it, in fact. Ruined by it, some would
say. Yes, it's a very different model from the one we're all used to. But it's also a better
model—not just for novices, but for geeks too.

Think about it: never lose data because you forgot to save. Quit applications with im-
punity. Retrieve old versions of documents at any time, in whole or in part. Build up
a nice arrangement of open documents and windows, knowing that your hard work
will not be trashed the next time you quit the application or need to restart for an OS
security update.

The final piece of the puzzle is not strictly document-related, but it puts the bow on
the package. When logging out or restarting, Lion presents an option (selected by de-
fault) to restore all open applications when you next log in. And relaunching a Lion-
savvy application, of course, causes it to restore its open documents.

Putting it all together, this means that you can log out or shut down your Mac with-
out being asked any questions by needy applications and without losing any of your
data or window state. When you next log in, the screen should look exactly the same
as it did just before you logged out. (In fact, Lion appears to "cheat" and briefly
presents a static image of your earlier screen while it works on relaunching your apps
and restoring your open documents. Sneaky, but an effective way to make state
restoration feel faster than it really is.)

Process model

If you were flipping out over the document changes described in the previous sec-
tion, buckle up, because the discomfort level is about to rise yet again.


tion, buckle up, because the discomfort level is about to rise yet again.

The small indicator lights shown beneath running applications in the Dock are now
optional in Lion.

Three of these applications are running

In pre-release builds of Lion, all applications in the Dock looked exactly the same,
running or otherwise. At the last minute, it seems Apple chickened out and enabled
the indicator lights by default.

Apple's message with this feature is a simple one, but also one that the nerdly mind
rebels against: "It doesn't matter if an application is running or not. You shouldn't
care. Stop thinking about it." Geek panic!

Remain calm. Let's start with the APIs. Sudden Termination, a feature that was intro-
duced in Snow Leopard, allows applications to indicate to the system that it's safe to
kill them "impolitely" (i.e., by sending them SIGKILL, causing them to terminate im-
mediately, with no chance for potentially time-consuming clean-up operations to exe-
cute). Applications are expected to set this bit when they're sure they're not in the
middle of doing something, have no open files, no unflushed buffers, and so on.

This feature enables Snow Leopard to log out, shut down, and restart more quickly
than earlier versions of Mac OS X. When it can, the OS simply kills processes instead
of politely asking them to exit. (When Snow Leopard was released, Apple made sure
its own applications and daemon processes supported Sudden Termination, even if
third-party applications didn't.)

Lion includes a new feature called Automatic Termination. Whereas Sudden Termi-
nation lets an application tell the system when it's okay to terminate it with extreme
prejudice, Automatic Termination lets an application tell the system that it's okay to
politely ask the program to exit.

But wait, isn't it always okay for the OS to politely ask an application to exit? Isn't
that what's always happened in Mac OS X on logout, shutdown, or restart? Yes, but


that what's always happened in Mac OS X on logout, shutdown, or restart? Yes, but

what makes Automatic Termination different is when and why this might happen. In
Lion, the OS may terminate applications that are not in use in order to reclaim re-
sources—primarily memory, but also things like file descriptors, CPU cycles, and
processes.

You read that right. Lion will quit your running applications behind your back if it
decides it needs the resources, and if you don't appear to be using them. The heuristic
for determining whether an application is "in use" is very conservative: it must not be
the active application, it must have no visible, non-minimized windows—and, of
course, it must explicitly support Automatic Termination.

Automatic Termination works hand-in-hand with autosave. Any application that
supports Automatic Termination should also support autosave and document re-
store. Since only applications with no visible windows are eligible for Automatic Ter-
mination, and since by default the Dock does not indicate whether or not an applica-
tion is running, the user might not even notice when an application is automatically
terminated by the system. No dialog boxes will ask about unsaved changes, and
when the user clicks on the application in the Dock to reactivate it, it should relaunch
and appear exactly as it did before it was terminated.

This is effectively a deprecation of the Quit command. It also, perhaps coincidentally,
solves the age-old problem of former Windows users expecting applications to termi-
nate when they no longer have any open windows. When Automatic Termination is
enabled in an application, that's exactly what will happen—if and when the system
needs to reclaim some resources, that is.

As if all of this isn't enough, Lion features one final application management twist.
When an application is terminated in Lion, all the usual things appear to happen. If
the running application indicator is enabled, the small dot will disappear from be-
neath the application's Dock icon. Assuming it's not a permanent resident, the appli-
cation icon will disappear from the Dock. The application will no longer appear in
the command-tab application switcher, or in Mission Control. You might therefore
conclude that this application's process has terminated.

A quick trip to the Activity Monitor application or the "ps" command-line utility may
dissuade you of that notion. Lion reserves the right to keep an application's process
around just in case the user decides to relaunch it. Upon relaunch, the application ap-


around just in case the user decides to relaunch it. Upon relaunch, the application ap-
pears to start up instantly—because it was never actually terminated, but was simply
removed from all parts of the GUI normally occupied by running applications.

That's right, gentle readers. In Lion, an ostensibly "running" application may have no
associated process (because the operating system automatically terminated it in order
to reclaim resources) and an application may have a process even when it doesn't ap-
pear to be running. Applications without processes. Processes without applications.
Did Lion just blow your mind?

The pitch

The application and document model changes in Lion are a radical break with the
past—the past of the desktop, that is. Everything described above has existed since
day one on Apple's mobile platform. Indeed, iOS is the most compelling argument in
favor of the changes in Lion. For every objection offered by a long-time personal com-
puter aficionado, there are millions of iOS users countering the argument every day
with their fingers and their wallets.

These changes in Lion are meant to reduce the number of things the user has to care about.
And while you may think you really do need to care about when your documents are
saved to disk or when the memory occupied by an application is returned to the sys-
tem, you may be surprised by how little you think about these things once you be-
come accustomed to the computer managing them for you. If you're an iOS user,
think about how often you've wanted a "Save" button in an app on your iPhone or
iPad, for example.

So that's the pitch: Lion will bring the worry-free usability of iOS application and
document management to the Mac. For the vast majority of Mac users, I think it will
be an easy sale.

The reality

There's a common thread running through all of the application and document mod-
el features described above: they're all opt-in, and developers must add code to their
applications to support them. Apple has some ability to hasten the transition to Lion-
savvy applications through evangelism, positive reinforcement (the carrot), and the
increasing popularity of the Mac App Store (the stick). But no matter what Apple
does, the idyllic image of an iOS-like experience on your Mac will take a long time to


does, the idyllic image of an iOS-like experience on your Mac will take a long time to
materialize.

In the meantime, it's easy to envision a frustrating hodgepodge of old and new Mac
applications running on Lion, making users second-guess their hard-won computing
instincts at every turn. What I think will actually happen is that the top-tier Mac de-
velopers will quickly add support for some or all of these new features and users will
start to look down on applications that still behave the "old way." I'm sure that's how
Apple hopes things turn out, too.

Internals

The previous release of Mac OS X focused on internal changes. My review did the
same, covering compiler features, programming language extensions, new libraries,
and other details that were mostly invisible to end-users.

Lion is most definitely not an internals-focused release, but it's also big enough that it
has its share of important changes to the core OS accompanying its more obvious
user-visible changes. If this is your first time reading an Ars Technica review of Mac
OS X and you've made it this far, be warned: this section will be even more esoteric
than the ones you've already read. If you just want to see more screenshots of new or
changed applications, feel free to skip ahead to the next section. We nerds won't
think any less of you.

Security

Apple's approach to security has always been a bit unorthodox. Microsoft has spent
the last several years making security a top priority for Windows, and has done so in
a very public way. Today, Windows 7 is considered vastly more secure than its wide-
ly exploited ancestor, Windows XP. And despite the fact that Microsoft now distrib-
utes its own virus/malware protection software, a burgeoning market still exists for
third-party antivirus software.

Meanwhile, on the Mac, Apple has only very recently added some basic malware
protection to Mac OS X, and it did so quietly. Updates have been similarly quiet, giv-
ing the impression that Apple will only talk about viruses and malware if asked a di-
rect question about a specific, real piece of malicious software.

This approach is typical of Apple: don't say anything until you have something


meaningful to say. But it can be maddening to security experts and journalists alike.

As for end-users, well, until there is a security problem that affects more than a tiny
minority of Mac users, it's hard to find an example of how Apple's policies and prac-
tices have failed to protect Mac users at least as well as Microsoft protects Windows
users.

Sandboxing

Just because Apple is quiet, that doesn't mean it hasn't been taking real steps to im-
prove security on the Mac. In Leopard, Apple added a basic form of sandboxing to
the kernel. Many of the daemon processes that make Mac OS X work are running
within sandboxes in Snow Leopard. Again, this was done with little fanfare.

Running an application inside a sandbox is meant to minimize the damage that could
be caused if that application is compromised by a piece of malware. A sandboxed ap-
plication voluntarily surrenders the ability to do many things that a normal process
run by the same user could do. For example, a normal application run by a user has
the ability to delete every single file owned by that user. Obviously, a well-behaved
application will not do this. But if an application becomes compromised, it may be
coerced into doing something destructive.

In Lion, the sandbox security model has been greatly enhanced, and Apple is finally
promoting it for use by third-party applications. A sandboxed application must now
include a list of "entitlements" describing exactly what resources it needs in order to
do its job. Lion supports about 30 different entitlements which range from basic
things like the ability to create a network connection or to listen for incoming net-
work connections (two separate entitlements) to sophisticated tasks like capturing
video or still images from a built-in camera.

It might seem like any nontrivial document-based Mac application will, at the very
least, need to declare an entitlement that will allow it to both read from and write to
any directory owned by the current user. After all, how else would the user open and
save documents? And if that's the case, wouldn't that entirely defeat the purpose of
sandboxing?

Apple has chosen to solve this problem by providing heightened permissions to a
particular class of actions: those explicitly initiated by the user. Lion includes a trust-
ed daemon process called Powerbox (pboxd) whose job is to present and control


ed daemon process called Powerbox (pboxd) whose job is to present and control
open/save dialog boxes on behalf of sandboxed applications. After the user selects a
file or directory into which a file should be saved, Powerbox pokes a hole in the ap-
plication sandbox that allows it to perform the specific action.

A similar mechanism is used to allow access to recently opened files in the "Open Re-
cent" menu, to restore previously open documents when an application is re-
launched, to handle drag and drop, and so on. The goal is to prevent applications
from having to request entitlements that allow it to read and write arbitrary files. Oh,
and in case it doesn't go without saying, all sandboxed applications must be signed.

Here are a few examples of sandboxed processes in Lion, shown in the Activity Mon-
itor application with the new "Sandbox" column visible:

Sandboxed processes in Lion

Earlier, the Mac App Store was suggested as a way Apple might expedite the adop-
tion of new Lion technologies. In the case of sandboxing, that has already happened.
Apple has decreed that all applications submitted to the Mac App Store must be sand-
boxed, starting in November.

Privilege separation

One limitation of sandboxing is that entitlements apply to an entire process. A sand-
boxed application must therefore possess the superset of all entitlements required for
each feature it provides. As we've seen, the use of the Powerbox daemon process pre-

Mac OS X Lion - John Siracusa's Ars Technica Review

Mac OS X Lion - John Siracusa's Ars Technica Review

Recomendados

Recomendados

Más contenido relacionado

Similar a Mac OS X Lion - John Siracusa's Ars Technica Review

Similar a Mac OS X Lion - John Siracusa's Ars Technica Review (20)

Último

Último (20)

Mac OS X Lion - John Siracusa's Ars Technica Review