Mac OS X Mavericks - John Siracusa's Ars Technica review

23/10/13 14:12OS X 10.9 Mavericks: The Ars Technica Review | Ars Technica

Pagina 1 di 98http://arstechnica.com/apple/2013/10/os-x-10-9/

Read it your way

Don't want to read an article this long on theWeb?

Ars Technica premier subscribers candownload a (free) Kindle, iBooks-compatibleEPUB, or PDF version of the complete reviewfrom the links in the upper right of each articlepage.

OS X 10.9 Mavericks: The Ars Technica Review

Aurich Lawson / Thinkstock

After a dozen years and nine major releases, OS X has had a full life: the exuberanceof youth, gradually maturing into adulthood, and now, perhaps, entering its dotage.When I am an old operating system I shall wear… leather?

The 2011 release of OS X 10.7 Lion seemed to mark the natural endpoint of the "bigcat" naming scheme. But Apple couldn't resist the lure of the "cat, modifier cat" namingpattern, releasing OS X 10.8 Mountain Lion a year later. Perhaps it just wanted to giveits cat nine lives.

The 10th major release, OS X 10.9 Mavericks, is named after an awkwardly plural Cal-ifornia surfing spot, finally ending the feline dynasty. But what part of the operatingsystem's existence is this? The afterlife?

When it comes to OS X, many people are sufferingfrom the end-of-history illusion: the belief thatwhile the Mac platform has consistently experi-enced significant enhancements in the past, it willsomehow not continue to grow and mature in thefuture.



Non-subscribers can buy the e-book from theiBookstore or the Amazon Kindle store.

So let's readjust our perspective. Perhaps the firstseven big-cat releases were OS X's early childhood:birth, potty training, learning to walk and talk, andso on, culminating in some form of self-actualization.

With Lion, the Mac entered an awkward adolescence, acquiring a newfound concernabout what the other kids were doing. Accordingly, OS X's last two releases includedseveral naked attempts to ape the look and feel of its more successful sibling, iOS.

But that was all before last year's ouster of Scott Forstall, senior vice president of iOSSoftware. By all accounts, Forstall was one of the driving forces behind the iOS aes-thetic that Lion and Mountain Lion so enthusiastically embraced. Jony Ive's iOS 7strikes off in a bold new direction based on a philosophy that Apple is eager to gener-alize to the company as a whole—leaving OS X holding the stitched-leather bag.

An OS out to sea

Let's say we accept that this is not the end of history and that OS X will continue toevolve. To what end? Aside from undoing the most egregious peer-pressure-motivat-ed interface changes, what should this first non-cat release of OS X do differently fromits predecessors?

One option would be to continue to follow iOS's lead, switching gears from rich tex-tures and simulations of analogous physical products and setting off in pursuit of thenew, spare iOS 7 aesthetic. I'll spoil it for you: Apple hasn't chosen this path—not yet,anyway. Time and resource constraints alone could explain this choice. After all, Ap-ple didn't even have the iPad version of iOS 7 ready in time for WWDC this year. Aninterface overhaul in Mavericks was clearly out of the question.

Mavericks is also not an internals-only release like Snow Leopard, which famouslypromised "no new features." There are new features in Mavericks, even new bundledapplications.

To some degree, the content of any OS release is determined by what did and didn'tmake the deadline for the previous release. There are exceptions, like Fusion Drive,which didn't quite make it into Mountain Lion but also couldn't wait for the next ma-jor OS release because it was a prerequisite for some new hardware products.

Nevertheless, Apple does try to give each new OS some sort of theme. Mavericks is



the first California-themed release of OS X, named after "places that inspire us here inCalifornia," according to Craig Federighi, who says this naming scheme is intended tolast for at least the next 10 years. The pressure is on for Mavericks to set a new direc-tion for the Mac platform.

According to Apple, Mavericks has a dual focus. Its first and most important goal is toextend battery life and improve responsiveness. Secondarily, Mavericks aims to addfunctionality that will appeal to "power users" (Apple's words), a group that may befeeling neglected after enduring two releases of OS X playing iOS dress-up.

Is that enough for Mavericks to live up to its major-release version number and tokick off the next phase of OS X's life? Let's find out.

Table of Contents

IntroductionPurchase and installationBrandingInterfaceSafariiCloud KeychainNotification CenterThe FinderTags

ImplementationLabelsTags

iBooksMapsMultiple displaysEnergy saving

App NapApp Nap PolicyEnergy best practicesApp Nap API

VisibilityTimer tolerance



User activitiesEnergy shamingBackground tasksCentralized task schedulingCompressed memoryBattery benchmarksEnergy summary

Responsive scrollingiCloud Core DataSprite KitGrab Bag

System PreferencesGeneralDesktop & Screen SaverLanguage & RegionInternet AccountsSharingParental ControlsApp StoreDictationAccessibility

Integrated graphics improvementsTerminal cwd restorationSpecial characters popoverSystem font

RecommendationsChangeover

Purchase and installation

Lion was the first download-mostly release of OS X, and Mountain Lion was the firstdownload-only release. Mavericks breaks no new ground in the realm of product dis-tribution. As expected, it's available only through the Mac App Store.

With the transition away from physical media complete, Apple is free to focus on oneof the intended benefits of downloadable OS updates: adoption rate.

At WWDC, Tim Cook made a point of bragging about iOS's adoption rate. After less



than 10 months on the market, 93 percent of iOS userswere using the latest version, iOS 6. (iOS 7 is well on itsway to matching that performance, with a 64 percentadoption rate 34 days after its release.)

Earlier in the same presentation, Craig Federighi sharedsome less impressive statistics about Mountain Lionadoption: 35 percent after six months. Did it pass 90 per-cent four months later? If it did, I imagine Apple would have said so.

After eliminating the trip to the store (or the package delivery), the other major knobApple can turn to drive adoption of new OS X releases is the price. And turn it has,dropping the price of the Mac operating system steadily over the past five years, hit-ting $19.99 with Mountain Lion. Mavericks follows the trend to its logical conclusion,finally joining iOS at the magical price point of free. Mac users who are still stubborn-ly clinging to Snow Leopard are unlikely to be dislodged, but anyone running Lion orMountain Lion is sure to feel the gravitational pull of an OS upgrade that's just oneclick and $0 away.

In a refreshing change of pace, Mavericks does not cut off support for any additionalMac hardware. If your Mac can run Mountain Lion, it can run Mavericks. For com-pleteness, here's the list of supported models:

iMac (Mid 2007 or newer)MacBook (Late 2008 Aluminum, or Early 2009 or newer)MacBook Pro (13-inch, Mid-2009 or later; 15-inch, Mid/Late 2007 or newer)MacBook Air (Late 2008 or newer)Mac mini (Early 2009 or newer)Mac Pro (Early 2008 or newer)Xserve (Early 2009)

Like its feline ancestors, a single copy of Mavericks can be installed on "each Apple-branded computer […] that you own or control" plus two additional copies within vir-tual machines. There's still no DRM, no serial numbers, and no product activation. Iknow I repeat this every year, but it's worth emphasizing. Despite having arguablybuilt a large portion of its current digital media empire on the back of its FairPlaycopy protection system, Apple still seems to view DRM as a net negative that shouldbe avoided, when possible.



Branding

Time was when I'd review OS X branding trends by lining up images of cardboardproduct boxes or optical discs. After the transition to download-only, Apple's market-ing materials and website must fill the gap. Our first glimpse of Mavericks brandingwas on a banner visible just before the WWDC 2013 keynote.

Mavericks banner at WWDC 2013.

Pierre Rothmaler

The thin "X" is an obvious echo of iOS 7's design—despite the fact that, as we wouldsoon find out in the keynote, Mavericks does not adopt the iOS 7 interface style.Apple's website revealed what would become the more common logo for the OS.



Enlarge / The Mavericks preview section of apple.com.

The "X" is thinner than in the past, but not quite iOS-7 thin. It's placed inside a circlethat initially reads like an optical disc—or does if you're a Mac user of a certain age,anyway. But sometimes a circle is just a circle. Behind it, showing through the logo, isthe attractive new default desktop image showing a wave, presumably from theeponymous surfing location.

I'm mentioning all of this not (just) because I'm interested in how Apple markets itsproducts, but because the branding of Mavericks reveals a tension that appears inboth the aesthetic and functional design of the OS itself. Mavericks is not iOS 7, butit's also not Mountain Lion. Mavericks doesn't get an all-new interface, but it surelycan't carry on with many of its bundled applications looking like iOS 6doppelgängers. In the next section, we'll see how Apple manages this tension.

Interface

At first glance, Mavericks looks like Mountain Lion. There are no major changes to theappearance of standard controls like scroll bars and buttons; the Dock looks the same(in its default position, anyway); most application icons have not changed.

But poke around a bit and you'll spot a few differences. Move the Dock to the side toreveal its new smoked glass appearance. It's a nice match for the attractive gray metal



Enlarge

look introduced in Mountain Lion, though the smoked glass Dock istranslucent instead of reflective like the metal Dock.

The gray linen texture that invaded OS X in a big way a few years agohas now been expunged. The Notification Center sidebar and the loginscreen are now a soothing slate gray.

The new linen-free login window.

No linen in Notification Center either.



Linen also no longer covers secondary displays when full-screen mode is active; moreon that later.

With these changes, Mavericks can be seen as continuing to follow the lead of iOS 7,which also notably parts ways with the linen texture. But Mavericks is unwilling—orat least unable—to follow iOS 7 the rest of the way down the road. For now, Maver-icks has settled for expelling as much visual and interactive baggage from iOS 6 aspossible.

Consider the state of the Address Book application in Lion. It was the spitting imageof its iOS 6 counterpart on the iPad: a beautifully drawn leather-bound book with ared cloth bookmark. But the artwork was more misleading than helpful. The applica-tion looked like a book, but it didn't behave like one. Worse, important functionalitywas sacrificed on the altar of those graphics. The third pane used to display contactgroups was removed entirely; an open book has two sides, not three, after all.

In Mountain Lion, the newly renamed Contacts application brought back the groupspane, but it did so by cutting into the contact list's space on the left side of the "book"graphic. Open books must have two equal sides, right?

Mavericks says enough is enough. The leather's gone, the fake pages are gone, thethree panes are independently resizable (more or less), even the title bar is bone-stock,and it's… boring?



The new look for the Contacts application: cucumbers with cottage cheese.

The story's the same for the Notes application. Once an iOS 6 lookalike sporting tornbits of paper on a yellow legal pad, it's now stripped of all pretense. Also possibly re-moved: beauty, fun.



The new Notes applications does not stand out in a crowd.

Calendar is straight up the middle, with just a touch of iOS 7's super-lightweight text(e.g., the year) mingling somewhat awkwardly with the other typefaces.

In Mavericks, gray is the new Corinthian leather.



In Mavericks, gray is the new Corinthian leather.

When Lion was released, here's what I wrote about its stitched-leather calendar appli-cation:

The immediate, visceral negative reaction to the rich Corinthian leather ap-pearance had little to do with usability. What it came down to—what firstimpressions like these always seem to come down to—is whether or notyou think it's ugly. People will take "really cool-looking but slightly harderto use" over "usable but ugly" any day.

The freshly undecorated applications in Mavericks may test that assertion. Contactsand Calendar look plain compared to their previous incarnations; to my eye, Notesborders on ugly.

Don't get me wrong, in the case of applications like Contacts, I'm all for excising themisleading graphics and returning the functionality that was removed in service ofthem. But that kind of surgery appears to be the only significant change to these appli-cations in Mavericks. Apple took the Mountain Lion versions, removed the graphicalfrills, and updated the UI enough to work correctly without them.

I'm not sure there were any better options given the time constraints. Leaving theseapplications unmodified would have made OS X look like even more of an old fogeynext to iOS 7 than it already does. An OS-wide overhaul (following the iOS lead ornot) would have easily pushed Mavericks out into next year, blowing Apple's annualrelease schedule. And if an interface overhaul is in the cards for OS X in the next yearor two, a fresh rethinking of each application within the constraints of the current OSX look might have been wasted effort (in addition to making Mavericks late).

And yet there are places where hints of iOS 7 peek through. The icon for the newMaps application, for example, looks like an OS X-style application icon with iOS 7'scolor palette and smooth gradients applied to it. The iBooks application icon takes thislook one step further. The new iCloud preference pane icon looks like a straight liftfrom iOS 7.



Maps, iBooks, and iCloud have icons that show more than a little of iOS 7'sinfluence.

You might expect the Calendar, Contacts, and Notes icons to have been revised in thestyle of the new Maps icon to reflect their newly chastened interfaces. Nope, no timefor that either, I guess.

These applications have changed, but their icons still reflect their pre-Mav-ericks interfaces.

Many applications haven't been modified at all in Mavericks. Game Center retains itstacky green felt and wood. Reminders still looks like textured black… something sur-rounding white note paper. Messages still sports glossy text bubbles.

The influence of both iOS 7's "frosted glass" header elements and the sadly misguidedtranslucent OS X menu bar can be felt in the new list-view headers in the Finder.

In what situation is it important to see the App Store application peekingthrough the header?



I can think of only one practical use for this effect: to indicate that there's more contentabove the current scroll position when no scroll bar is visible to communicate this in-formation. At all other times, this transparency only serves to slightly impair the read-ability of the column headers.

And then there's the crazy sparkle effect that appears around newly installed applica-tions in Launchpad.

Apps, exciting and new…

The same effect is used when a new Dashboard widget is installed. I'm tempted to saythis is no more gaudy than the water-ripple effect used when a new instance of a wid-get is placed on the Dashboard, but in the context of the overall trend away from os-tentatious ornamentation across Apple's product line… yeah, it does seem a littleworse.

In short, the look and feel of Mavericks is a mixed bag. The iOS-inspired interface di-vergences introduced in Lion and refined in Mountain Lion have been partially rolledback in Mavericks, but there's still much more to be done. I look forward to the daythat the OS X interface will finally stop backtracking and start moving forward again.

Safari

The most important changes to Safari in Mavericks are internal. Two years ago, Lionincluded a version of Safari based on the WebKit2 engine, which separated the task ofpage rendering and JavaScript execution into an external process, mostly for securityreasons.

WebKit2 was a reaction to Chrome's multi-process architecture, which uses multipleWebKit processes to handle page rendering. Google included the multi-process codein the Chromium project, not in WebKit. Before creating WebKit2, Apple askedGoogle if it was willing to contribute Chromium's multi-process code to the WebKitproject. Google declined, leaving Apple to create its own solution. Apple implement-



ed its multi-process system in the WebKit engine itself, benefiting any application thatuses WebKit.

Unfortunately, the WebKit2 era of Safari has been marred by chronic instability.When Safari's lone back-end Web rendering process gets wedged, users are greetedwith the all-too-familiar "webpages are not responding" dialog; forward progress re-quires reloading every open webpage in every tab in Safari. This problem has notgone away in the years since Lion was released.

Contrast this to Google's Chrome browser, which has been rock-solid over the sameperiod. The cumulative effect of these years of Safari instability has made me start toquestion whether Apple still has the chops to keep up in the fast-paced world of Webrendering engines.

Safari version 7, included in Mavericks, is Apple's answer. It sports a new process-per-tab architecture, finally following in Chrome's footsteps—though this change ispart of WebKit itself, not just the Safari application. It's too early to tell if this changewill restore Safari's stability, but I can report that I have not seen a single Safari crashor "webpages are not responding" dialog in all my Mavericks testing. (I've seen manyin Safari 6 while writing this review in Mountain Lion.)

The new architecture also affords the ability to examine the behavior of individualbrowser tabs using the Activity Monitor application.

At last, separate Safari Web Content processes for each tab.

It would be nice if this feature was built into Safari itself, like Chrome's Task Manager,so each "Safari Web Content" process could be linked to a specific open tab.

Safari's first-run experience reveals most of its new user-visible features. The old TopSites, a concave pseudo-3D wall of website thumbnails, has been replaced by a plain,



flat grid of thumbnails. The old Reading List sidebar has been replaced by a unifiedsidebar containing Bookmarks, Reading List, and a new feature called Shared Links.

Safari's new sidebar and less flamboyant Top Sites layout.

Shared Links shows links from the social network accounts added through the Inter-net Accounts preference pane. For example, if a Twitter account is registered, SharedLinks will show only the tweets that contain links.

Reading List gets a mild facelift to fit in with the new sidebar styling. Two-fingerswiping past the bottom of the page when viewing an item from the Reading Listloads the next item in the list. It's as if all items form a single, long webpage.

The old bookmarks manager and history viewer are still available via separate itemsin the Bookmarks and History menus, respectively. Editing bookmarks in the newsidebar is frustrating (the interface is made for navigation, not modification), so don'tforget about the old interfaces.

After a brief absence, the "+" button has returned to its former home nestled in the leftside of the address bar. There is no separate incarnation of this button that can beplaced anywhere on the toolbar, nor is there an option to remove it from the addressbar. Holding down the mouse button (but not right-clicking) on the "+" button reveals



a menu for adding the current webpage to all of Safari's various link storage locations.

The "add" button is here to stay in Safari 7, but at least it knows a few newtricks.

While the additional functionality is welcome, I'm not sure the frequency with whichpeople add bookmarks, Top Sites, or Reading List items warrants such prominent,permanent placement for this button.

Browser plug-ins can now be managed on a per-website basis, with five options: Ask,Block, Allow, Always Allow, and Run in Unsafe Mode. The same options exist for thedefault behavior when visiting a new website. The preferences window convenientlysplits the list of websites into those that are currently open in Safari and all the rest.



Safari's new per-site, per-plug-in security settings.

Even when set to "Allow" a plug-in, Safari will block it if there are known security is-sues with the installed version of that plug-in. (Updated plug-in security informationis automatically distributed to all network-connected Macs using the same mecha-nism as the existing malware signature information.) The "Allow Always" settingoverrides this restriction, permitting plug-ins to load even if they have known vulner-abilities.

Most popular plug-ins run in a sandbox by default, including QuickTime, Flash Play-er, Silverlight, and Oracle's Java plug-in. The "Unsafe" plug-in setting instructs Safarito run the plug-in outside the sandbox. This is intended as a last resort for plug-insthat don't yet run correctly inside a sandbox. (This setting also allows plug-ins to loaddespite the existence of known security problems with the installed version.)

The "Ask" setting is the default when visiting a new website. It presents a sheet withoptions to trust, block, or disallow for now (but ask again later).



When configured to "Ask" about plug-ins on the first visit to a website, Sa-fari presents these options.

Blocked plug-ins are reported as such in the browser window. Clicking on theblocked plug-in message will ask for confirmation before allowing it to load.

Click to load this plug-in…and all other instances of the same plug-in onthis website.

Clicking the "Trust" button doesn't just allow this particular instance of the plug-in toload. It changes the setting for this plug-in for the entire website to "Allow." This isunlike the once-popular ClickToFlash in which clicking on a particular instance of aplug-in did not confer website-wide permission to load that plug-in in the future.



Like last year's Gatekeeper feature, Safari's new plug-in security settings have sensibledefaults while also offering an easy way to opt out. Automatically disabling plug-inswhen vulnerabilities are discovered will likely annoy users a lot more than Gatekeep-er does, but it's preferable to the alternative of leaving users exposed until they realizethere's a problem and upgrade on their own—a sequence of events that represents asurprisingly high hurdle for most users. After all, most people don't read tech newson a regular basis, scanning for the latest Flash or Java exploits.

There's also a new preference to "Stop plug-ins to save power," which is part of a fea-ture Apple calls Safari Power Saver. Even if the preference for a website is set to "Al-low," the Power Saver feature will stop plug-ins from running if they do not appear tobe the main content on the page.

Translating that from abstract to concrete, it means that you can enable Flash for awebsite and Safari will still try to block auto-playing Flash ads that appear around thecontent on that website. There's no visible indication that it's happening until youmouse over one of the frozen ads.

Safari Power Saver in action: a Flash sidebar ad loads, but it's not allowed torun until clicked.

Safari uses a fuzzy set of rules to distinguish plug-in "content" (e.g., the movie traileryou came to the website to see) from extraneous items that should not be allowed toauto-play (e.g., sidebar or banner ads). In practice, it works well. Credit the banal pre-dictability of ad-heavy website layouts and ad banner sizes.

The default Web browser is an incredibly important part of any modern operating



system. Though we geeks may routinely install alternate browsers, application down-load and installation on OS X is not yet as simple as it is on iOS. (It also doesn't helpthat popular alternatives like Chrome and Firefox aren't available through the MacApp Store.) Safari is "the Web" for most Mac users; it needs to be awesome.

Apple clearly realizes this, as it continues to pour resources into Safari in release afterrelease. Safari 7 is a standard-bearer for many of the flagship technologies in Maver-icks, and its focus on stability, security, and energy-saving is a microcosm of thewhole OS. I came very close to switching to Chrome as my default Web browser dur-ing the reign of Safari 6. Safari 7 has pulled me firmly back into the Apple camp.

iCloud Keychain

Few lamented the end of MobileMe. Apple's much-maligned package of network ser-vices was in trouble from day one, and it never became the beloved, essential productthat Apple envisioned. When iCloud was introduced in 2011, it was welcomed as aliberator.

The transition from MobileMe to iCloud was not without its pitfalls—and losses. Theend of support for Apple-hosted websites produced the biggest short-term turmoil,but the writing had been on the wall for the iWeb application for years.

Passwords, on the other hand, are (sadly) not going away any time soon. MobileMe'sKeychain synchronization feature was one of the highlights of the service for me. Toreplace it, iCloud offered exactly nothing. This was an ongoing pain, becoming worseas the Keychain databases stranded on each isolated Mac slowly diverged from eachother.

In Mavericks, blessed relief is just one checkbox away.

The new iCloud Keychain isn't exactly the same as MobileMe's Keychain sync. Ratherthan synchronizing the entire contents of the Mac's Keychain database, Mavericksadds a new "iCloud" keychain alongside the local "login" and "System" keychains.



iCloud gets its own separate keychain.

If the iCloud Keychain is subsequently disabled, the iCloud keychain highlighted inthe screenshot above is replaced with a "Local Items" keychain that has the same con-tents as the iCloud keychain. Any items added to the Local Items keychain will bepushed out to other devices when iCloud Keychain is re-enabled.

Enabling iCloud Keychain requires traversing a gauntlet of security-related questionsrivaled in OS X only by the recently revised File Vault disk encryption feature. Itstarts with a suggestion to enable a screen lock, if one is not already enabled, to pre-vent someone from walking up to your unattended Mac and having access to all yourcloud-synced passwords.

Heed Apple's advice (or click "Not Now"), then enter your Apple ID password to con-tinue. Next, you'll be asked to create an "iCloud Security Code." The default dialog re-quests a four-digit numeric code, but the "Advanced…" button leads to more options.

iCloud Security Code setup: 4-digit numeric, or…



iCloud Security Code "Advanced" options, including no security code at all.

You can forgo a security code entirely, ask to be prompted for a "complex" securitycode (i.e., a password instead of a 4-digit code), or ask Mavericks to generate a ran-dom security code. Random codes look a lot like File Vault recovery keys (e.g., DCLK-XZEX-XNEB-LGXJ-5UHB-89C3). The "complex" and "random" security code dialogboxes also suggest that people write down their security codes and keep them "in asafe place" because "Apple cannot recover a lost code."

Finally, if you didn't opt out of the security code entirely, you must enter a phonenumber that can receive SMS messages.

At last, the final step: a phone number to receive verification codes fromApple via SMS.



There's also a first-run setup wizard that will take new users through the same stepsbefore logging in for the first time.

All of this additional security comes into play when you want to enable iCloud Key-chain on a second device. At that point, you have two options. You can request ap-proval from another device where iCloud Keychain has already been enabled for thesame Apple ID. This request appears in the form of a standard notification dialog.

Approval from a trusted device is one way to activate iCloud Keychain onanother Mac.

If you choose to configure an iCloud Security Code, you can enable iCloud Keychainon a new device by entering all three of the following: your Apple ID password, yoursecurity code, and a verification code that Apple will send to the configured phonenumber via SMS.

Usability and security are often at odds with each other. iCloud Keychain bears thisout, presenting many more hurdles during the setup process than the MobileMe Key-chain sync feature that it belatedly replaces.

Once configured, it mostly works as expected, helpfully offering to remember user-names and passwords in applications like Safari, syncing them to all configured de-vices, and then auto-completing those values when they're requested later.



Safari's Keychain auto-fill, now powered by iCloud.

Safari's iCloud Keychain integration goes further, offering to auto-generate and thenremember passwords for the user.

Accepting the suggested password will also helpfully enter it in the password confir-mation field as well. Interestingly, Apple's own Apple ID account creation websiteranks the strength of the auto-generated password as merely "moderate."

Apple is not impressed by its own password suggestions.

By default, auto-fill still refuses to activate on websites that explicitly ask to disablethe feature. Again, the tension between usability and security surfaces. Digging intoSafari 7's preferences reveals a setting that promises to "[a]llow AutoFill even for web-sites that request passwords not be saved." Jackpot! But there are caveats. First, en-abling this override requires that the Mac be configured to lock the screen when idle.Second, Safari still fails to auto-fill passwords on some websites, most notably Apple'sown icloud.com.



For people with more complex needs, third-party password managers still fill an im-portant role. Similarly, the people for whom "cross-platform" means more than just"OS X and iOS" will continue to rely on the password management and sync featuresbuilt into Chrome and Firefox.

For everyone else, things are looking up. An Apple-made password manager that'sbuilt into the default Web browser on OS X and works across multiple Macs and iOSdevices was long overdue. It's sure to be a hit among people who—rightly—expectthis functionality to work without any third-party software.

Notification Center

Notification Center has become such an integral part of my daily use of OS X that Ijust spent a few moments searching my review of Lion for the word "notification" be-fore realizing that Notification Center was actually introduced just a year ago inMountain Lion. I'd say the feature has handily earned its place in the upper-right cor-ner of the screen, even if most of my interaction with it is through the preference paneand the various alerts and banners that appear during the day.

Mavericks takes the obvious next step and adds the ability to reply to a notificationright from the alert itself. This only works for a handful of Apple-supported applica-tions right now (e.g., instant messages using the Messages application, e-mail usingApple's Mail application) but the supported services have broad coverage: Facebook,Twitter, FaceTime, e-mail, instant message, calendar events, and reminders.

Simple, text-only replies can be sent directly from a notification alert using an inlineuser interface.

Replying to an instant message from within the notification.

The reply button on e-mail notification alerts will launch the Mail application and pre-



pare a reply. Despite the potential sophistication of an e-mail message (attachments,styled text, and so on), an inline e-mail reply interface would be a nice option. Maybenext year.

Cross-protocol replies are a pleasant surprise. An invitation to a FaceTime video chatoffers an inline instant-message reply option with a configurable set of canned an-swers (or freeform text), plus an option to add a reminder to get back to the personlater. The reminder will include a link to initiate a FaceTime chat with the person.

FaceTime requests can be replied to with an instant message or by creatinga reminder to contact the person later.

Instant messages can also be initiated from that weird little area at the top of the Noti-fication Center sidebar. It's getting pretty crowded up there. There's probably roomfor one more service icon before things start getting silly.

Send an instant message, tweet, or share something on Facebook orLinkedIn from the top of Notification Center.



Sending an instant message from Notification Center.

Each type of notification now has an option (on by default) to display even when thescreen is locked. Notifications that may contain sensitive information, such as e-mailsor instant messages, have an additional option to show message previews only whenthe screen is unlocked (the default), or always.

New privacy-related notification preferences.

These defaults are reasonable, but people who rely on screen savers for "casual" priva-cy in shared spaces may not want even the names of the people who are e-mailingand instant-messaging them to appear on their unattended screens. As always, theprice of Notification Center satisfaction is eternal vigilance.

Though Safari in Mountain Lion linked Web notifications to OS X's native notificationsystem, I've encountered few websites that take advantage of this feature. It onlyworks when a website is open in a Safari window, so admittedly, its usefulness is lim-ited.

Mavericks allows websites to use Apple's Push Notification service to post updateseven when Safari isn't running. This is a feature I really hope more websites adopt,though its confinement to a single platform surely makes it less appealing.

Finally, the big on/off switch at the top of the Notification Center sidebar has been re-



branded as Do Not Disturb and has been given a generous helping of preferences.

Notification Center's Do Not Disturb feature now has a full set of prefer-ences.

The part of me that Apple's beautiful, terrible walled garden has not yet stamped outof existence still yearns for a more open notification system that would allow third-party applications to enjoy the same interface integration as Apple's "blessed" applica-tions for each service. (I use Adium for instant messaging, Twitterrific for Twitter, andGmail for e-mail.) But overall, the notification system in Mavericks is a comfortableimprovement over its initial incarnation in Mountain Lion.

The Finder

It's not fair to say that Apple has entirely neglected the OS X Finder. It's been exten-sively revised multiple times over the years. It was even "rewritten" in Cocoa whenApple finally left Carbon behind for good a few years ago. Every major release of OSX includes some changes to the Finder.

But even as Apple has regularly laid hands on the Finder codebase, the applicationhas continued to suffer from a kind of spiritual neglect. My own decade-long frustra-tion with Apple's refusal to cleanly separate the "browser" features of the Finder fromthe rest of its functionality may (still) seem academic and unimportant to most Mac



users (though they are wrong). But more broadly speaking, it's clear that the OS XFinder is far from the center of the Mac experience that it once was back in the days ofclassic Mac OS. With the introduction of Launchpad in Lion, the Finder seems poisedto become even less relevant in the future.

Given all of this, perhaps we've been lulled into a false sense of complacency wherethe Finder is concerned. Then along comes Mavericks and, suddenly, the Finder hastabs.

Tabbed browsing in the Mavericks Finder. The wait is over.

Tabs! Can you believe it? This is such an obvious feature that entire third-party prod-ucts have been developed to fill the gap. Why didn't the Finder get tabs sooner? Wasthere some sort of philosophical objection to them? Did they conflict with the grandvision of the OS X Finder? Does such a thing even exist?

So many questions. No matter, tabs are here now, so let's move on. They look andwork almost exactly like Safari tabs. They can be rearranged by dragging, torn out toform new windows, and moved from one window to another. Holding down thecommand key while double-clicking a folder opens it in a new tab. (There's a prefer-ence to turn this off, in which case command-double-clicking opens a folder in a newwindow.) Files and folders can be dragged and dropped onto a tab in any window tomove or copy them. The proxy icon next to the folder name in the window title barcan be dragged onto the "+" icon in the tab bar of another Finder window to add anew tab with that location.

Since it's nearly impossible to add a major new feature to the Finder without furthercomplicating the interaction between "normal" and "browser" Finder windows(browser windows are the ones with toolbars), please note that it's now impossible to



hide the toolbar on a browser window that has two or more tabs. Non-browser Finderwindows don't have tabs, and apparently Apple couldn't decide what to do with thetabs when "transforming" a browser window into a normal window.

Of course, that transformation is at the very heart of the Finder's schizophrenic/amne-siac persona, leading to similar questions about other aspects of window state such assize, position, view style, and so on, which is why such window transformationsshouldn't be possible at all, under any circumstances. But I digress.

With the addition of tabs, the idea of a full-screen Finder window is a lot more attrac-tive. Happily, the upper-right corner of each Finder browser window sports a full-screen widget that does just what you'd expect.

Full-screen support and tabs would easily fulfill the low expectations for Finderchanges in a major OS X update, but Mavericks has one more thing…

Tags

At first glance, it appears that Finder Labels have been renamed "Tags" in Mavericks.Sure enough, the menu items and preferences in the Finder use the word "Tags"everywhere and "Labels" nowhere. The visual treatment of labels in the Finder's vari-ous views has also changed. Instead of highlighting the entire file or folder name (orthe entire row, in list view), a colored dot is displayed next to the name.

Finder Tags display: colored dots replace Mountain Lion's whole-row high-lights.

Setting aside everything else that is to come regarding Tags, this change alone finallyresolves the visual confusion caused by the line-highlighting appearance of labels in-troduced in Panther 10 years ago.



Stay in the Finder a bit longer and you'll undoubtedly discover that Tags are not quitethe same as labels. Attempt to change a file's Tag from blue to green, for example, andthe UI will gently explain what's about to happen.

Multiple Tags can be applied to a single file.

When an item has multiple Tags, the Finder will show multiple overlapping dots, upto a maximum of three, showing the three most recently applied thereafter.

Multiple Tags as displayed in the Finder: the three most recent Tags areshown as dots.

Careful observers will note that the text "Label:" that used to appear above the row ofcolored dots in the Finder's context menu has been replaced with "Tags…" in Maver-icks. As always on the Mac, that ellipsis denotes a menu item that leads to a furtherprompt for input. Select it and a popover appears, featuring a list of colored dotsalong with a text input field. (The same functionality can be triggered using the "EditTags" Finder toolbar item or the "Tags…" menu item in the File menu.)

Go ahead and type. If the text matches an existing Tag name, hitting the return keywill add the Tag and return the insertion point to the text field, now including thenewly added Tag.



The Finder Tags popover: add an existing Tag by clicking on it or typing itsname.

Type something that does not match an existing Tag and hit return to create a newTag. Enter the name of a Tag that's already added to the file and the Tag will bemoved to the end of the list of Tags.

The Finder Tags popover: create a new Tag or move an existing Tag.

The "Tags" section of the Finder's preferences window offers a way to assign colors to



The devious puzzle box that is the Finder's Tags preferences.

newly created Tags—though it's not immediately obvious how. (The answer: click thecircle to the left of the Tag name.) There are only seven colors to choose from, andthey can't be changed. More than one Tag can use the same color.

There's also a confusing drag-and-droparea at the bottom of the window.Though the text above it tries to explainhow it works, the lack of labels on thecolored dots at the bottom is confusing.

That horizontal line of colored dots rep-resents the list of Tags shown in theFinder's File menu and context menu.Mouse over each dot to see the name ofthe Tag that it represents. Do what thetext above the dots says and drag a Tagfrom the top list onto the bottom rowand yet more text appears to explainwhat will happen when you release themouse button and complete the dragoperation.

Frankly, this entire window is a user-interface disaster. And we haven't evenmentioned the checkbox to the right ofeach label. Can you guess what those do? (No, there's no tooltip when you hover overone.) I'll spoil the surprise. When that box is checked, it means the Tag appears in theFinder sidebar; unchecked means it doesn't.

And still, more mysteries remain. Just try to guess what an indeterminate checkbox(i.e., one with a horizontal line in it instead of a check mark) is meant to indicate. (No,still no tooltip on hover!) Give up? I almost did. Here's what it means.

When a Tag that has never been added to any file before is added to a file for the firsttime, that Tag automatically appears in the Finder sidebar (at the very top). But sincethe user didn't explicitly ask for that to happen, the preferences window doesn't showa check mark in the checkbox; it shows the indeterminate marker instead.



You were just about to guess that, right? Thankfully, the fate of the OS—or even justthe Finder—doesn't hinge on this one preferences window. But good gravy, is it evera mess.

The rest of the Finder's integration of Tags is smoother. Selecting a Tag in the Findersidebar runs a Spotlight search for all files with that Tag. (As far as I can tell, there isno way to select multiple Tags in the sidebar; use a full Spotlight search to find fileswith any or all of a set of Tags.) Drag the Tags in the sidebar to reorder them.

When a Tag is selected in the Finder sidebar, dragging a file into that window willadd the selected Tag to the file (which will in turn make the file match the search crite-ria and appear in the window).

As usual, the same sidebar appears in open/save dialog boxes. The standard save dia-log also includes a new field for entering or modifying Tags. This is convenient, but itmay also be confusing for some people. When the Tags field is empty, it looks exactlylike the file name field that's directly above it.

Add tags when saving a document—just make sure you enter them in thecorrect field.

I've done a double-take several times when saving documents in Mavericks due tothis "clone" text field. It's all too easy for me to picture a less experienced user tryingto type a file name into the Tags field and not understanding the subsequent errormessages.



Tags are also editable using the title bar pop-up menu introduced in Lion for docu-ment versioning.

Move over, versions. Tags now get pride of place in the title bar pop-upmenu.

The old "Move To…" command has been replaced with a pop-up menu containingiCloud folders, favorites, devices, and recent destinations, with an "Other…" item atthe bottom. The document-versioning features that used to live in the title bar pop-upmenu remain accessible via the File menu's "Revert to…" submenu.

Tags implementation

File system metadata in OS X has had an extremely bumpy road. The folks fromNeXT wanted no part of the metadata inherited from classic Mac OS for both philo-sophical and technical reasons. Their proposed replacement: nothing.

That's all ancient history now. We may still be stuck with the practice of encoding filetype information in the file name like a bunch of animals, but in the end, file systemmetadata did eventually come to OS X in a big way, as predicted.

The turning point came in Mac OS X 10.4, which added support for arbitrarily extensi-ble file system metadata. No longer were we confined to just a file name, a few dates,and some permissions and ownership information. Now we could attach any infor-mation to a file by adding arbitrary name/value pairs.

OS X itself was the first and biggest beneficiary of this feature, using it to implementeverything from low-level features like access control lists to flagship marketing fea-tures like Time Machine. In Mavericks, it's natural to assume that Tags leverage thesame mechanism. Sure enough, they do—though not quite in the way I expected. But



before we get to that, let's consider how the legacy Label metadata is stored.

Labels

Labels were introduced way back in System 6 in 1988. Since Apple made both theFinder and the file system, it reserved a place in the file system metadata for what itcalled "Finder Info." This structure contained information useful to the Finder (usuallypacked into bit fields—hey, it was 1988), including three bits for the Label color.

It would be nice if file system details from 1988 had little bearing on the Mac of today.Alas, OS X continues to use a file system derived from the very same one in use whenFinder Labels were created. The Finder Info data structure is in the same old locationand format in the file system.

As a nod toward modernity, Finder Info is exposed in OS X through a "fake" extendedattribute named com.apple.FinderInfo. The code that reads and writes extendedattributes for files on HFS+ volumes checks to see if the attribute name is com.ap‐ple.FinderInfo and then branches to another code path that reads the actual HFS+Finder Info record from the file system. (The resource fork is exposed in a similar wayunder the com.apple.ResourceFork attribute name.)

The upshot is that the xattr command can be used to show Finder Info for a file. Inthis example, the "Red" Label has been applied to the file named Hello.

% xattr -p com.apple.FinderInfo Hello 00 00 00 00 00 00 00 00 00 0C 00 00 00 00 00 0000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

That 0C bit pattern represents the Red Label. Only three bits in the Finder Info are al-lotted for the Label color, which means there can be a maximum of seven Label colors(001 through 111, reserving 000 for when there's no Label). Red is color number 6:0x0C is 1100 in binary, but the last bit is not part of the Label's bitfield. We're leftwith 110, which is 6 in base ten.

Tags

When a Tag that has a color assigned to it is applied to a file in Mavericks, Label infor-mation is written to the Finder Info field exactly as described above, making Tags at



least partly backward-compatible with pre-Mavericks systems. As more colored Tagsare added to the file in Mavericks, the Label information changes to reflect the mostrecently applied Tag. If a Tag does not have a color assigned to it, the Label informa-tion is not modified.

The actual Tag information is stored in its own separate extended attribute namedcom.apple.metadata:_kMDItemUserTags. (As far as I know, this is a "normal"extended attribute, not a proxy for legacy HFS+ metadata like com.apple.Finder‐Info and com.apple.ResourceFork.) In this example, the "Green" and "Red" Tagshave been applied to the file Hello in that order.

% xattr -l Hello com.apple.FinderInfo:00000000 00 00 00 00 00 00 00 00 00 0C 00 00 00 00 00 00 |................|00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|00000020com.apple.metadata:_kMDItemUserTags:00000000 62 70 6C 69 73 74 30 30 A2 01 02 57 47 72 65 65 |bplist00...WGree|00000010 6E 0A 32 55 52 65 64 0A 36 08 0B 13 00 00 00 00 |n.2URed.6.......|00000020 00 00 01 01 00 00 00 00 00 00 00 03 00 00 00 00 |................|00000030 00 00 00 00 00 00 00 00 00 00 00 19 |............|0000003c

There's the expected 0C bit pattern in the Finder Info, since the "Red" was the last Tagapplied. The ASCII dump of the Tag metadata starts with the telltale bplist se-quence of a binary property list. With a little help from a hex editor and a text editorthat understands binary property lists, the content of the Tag metadata is revealed:

<?xml version="1.0" encoding="UTF-8"?><!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">



<plist version="1.0"><array> <string>Green2</string> <string>Red6</string></array></plist>

You can see the two Tag names, Green and Red, listed in the order they were added,along with their decimal Label color values (2 for Green, 6 for Red).

The format of the Tag information within the property list is pretty strange. Your eyesdo not deceive you; that is indeed a Unix newline character (0x0A) separating the Tagname from the decimal Label color value. Why the name and color are packed into asingle string value in the property list instead of being stored in separate <string>and <integer> values is beyond me. (Is this what prolonged exposure to file nameextensions does to the mind?)

Tags that have no color assigned to them appear as lone strings, with no newline orLabel color value:

...<array> <string>Green2</string> <string>Red6</string> <string>Essential</string></array>...

I was also initially surprised to find that information about Tags is stored in a singleextended attribute instead of using one extended attribute for each Tag, but it makessome sense given how Spotlight searching and indexing works. The mdls commandshows the Tag information under the expected key:

% mdls -name kMDItemUserTags Hello



kMDItemUserTags = ( Green, Red, Essential)

Note that the Label color values for the Tags are not exposed in the Spotlight metada-ta; only the Tag names are stored. The legacy Label information remains unchangedfrom Mountain Lion and earlier, with only the color value exposed to Spotlight:

% mdls -name kMDItemFSLabel Hello kMDItemFSLabel = 6

These implementation details may seem esoteric and inconsequential, but some ofthem do affect the user experience in significant ways. Sticking with the same seveninteger colors from the legacy Labels system affords Tags backward compatibility, butit also explains why Tags have only seven possible colors and why those colors can'tbe changed.

The use of plain strings as Tag values means that there's no central directory requiredfor Tags to show up correctly on shared files; any Mac can read and display the Tagnames. But the color associated with each Tag name may not match across systems. Ifmultiple users create a Tag named "Hot" but each chooses a different color for it, theinteger color value written to the Tag metadata for each file will be different. Whenviewing files with the "Hot" Label, the user will see the color she chose for "Hot," notthe one stored in the Tag metadata for the file.

Storing the Tag name and color in each file's metadata also means that changing aTag's color requires updating the integer color value in every file that has that Tag. Ofcourse, this can only be done to files that the current user has permission to modify.It's also potentially a time-consuming operation; Mavericks sometimes displays a dia-log with a progress bar when changing Tag colors. Renaming a Tag requires the sameprocess, with the same caveats.

There are many edge cases in this system. The Tag metadata in a file doesn't alwayscorrespond to the color displayed in the Finder and elsewhere. Changes to Tag namesand colors may not propagate to all files using that Tag. The order that Tags areadded to a file determines what Label color pre-Mavericks systems see.



Hopefully these edge cases will be rare in normal usage. For certain operations, theTags data storage implementation could have benefitted from a little more normaliza-tion. For example, if Tag names and colors were stored in a single location that themetadata stored with each file could reference, updating Tag names and colors couldbe done in constant instead of linear time. Unfortunately, that would make the preser-vation and display of Tag metadata for shared files much more difficult—impossiblein some cases.

Apple has chosen an imperfect system that favors backward compatibility and sim-plicity of implementation over worst-case performance and storage efficiency. In theend, I can't fault the company for it. But part of me still wants to see Apple tackle thethorny underlying issues of taxonomy and implementation efficiency head on.

iBooks

It's a bit embarrassing that Apple's iBookstore has existed for three years without away to read the books purchased there on a Mac. It's probably true that most peopleprefer to read e-books on an iOS device, but Amazon has had a Kindle reader for theMac available for years.

The Mac finally gets its due in Mavericks, which ships with Apple's first version ofiBooks for OS X. At any time in the past, say, two or three years, the next thing to ap-pear in this review would surely be a screenshot of an exquisitely drawn applicationwindow designed to look like a paper book. Today's Apple has other ideas.



iBooks: no stacks of paper, no cloth bookmarks, no leather covers. Just thewords, thank you.

That wasn't so hard, was it? We don't need drawings of leather covers or lighting ef-fects reproducing the shadows that fall on paper pages as they curve downward intoa spine. We just need the text, nicely displayed, and that's what iBooks provides.

The reading window has a small toolbar that fades in when the cursor hovers over thetop of the window, providing access to the table of contents, highlights and notes, ap-pearance options, search, and bookmarks.

There are limited but reasonable appearance options: three color themes, seven fontsin a dozen sizes, single- and double-page display modes, and full-screen support.Blessedly, there's also an option to turn off full justification and a separate option todisable automatic hyphenation.



Enlarge / Even the iBooks toolbar is understated (albeit non-standard). Theappearance options are simple but adequate.

Text layout options to satisfy most tastes. The defaults are shown.

Unlike in Kindle Reader for the Mac, the iBookstore is accessible directly from withinthe application. Unsurprisingly, it looks a lot like every other Apple media store; thisisn't a bad thing.



The iBookstore should look familiar to anyone who frequents Apple's otherdigital marketplaces.

iBooks can read DRM-free EPUB books in addition to books purchased from theiBookstore. It can also import and organize PDFs, but reading one launches OS X'sPreview application.

This is definitely a version 1.0 product. The pre-release versions suffered from the ex-pected crop of cosmetic and functional bugs. The network-resident store-that's-not-really-a-webpage is a bit clunky, often feeling strangely slower on the Mac than itdoes in iOS. And as with the Mac App Store, there's no equivalent of browser tabs ormultiple windows to make browsing the store a bit more flexible.

Apple got the important part right: iBooks provides a pleasant, uncluttered way toread iBookstore purchases on a Mac. It's about time.

Maps

Part of the reason that Apple abandoned Google maps in iOS 6 was that it was fallingbehind the Web and Android incarnations of Google Maps. The divorce was messy tosay the least. Apple has been scrambling to overcome a terrible launch and restorefaith in its new mapping service.



Should Mac users have felt slighted that only iOS devices had access to Apple mapsduring this past year? Perhaps not, but it doesn't matter now because Mavericks letsMac users join the ranks of Apple maps users. The predictably named Maps applica-tion should be familiar to anyone who has used Apple maps in iOS 6, right down tothe graphics and icons.

Sharing directions or map locations ranges from seamless to awkward. Send direc-tions to someone on a device running iOS 6 or later and the recipient will be sent rightinto the iOS maps application. Map locations are e-mailed as a map image and avCard attachment with the address. E-mail directions and the lucky recipient will geta PDF(!) showing the route and turn-by-turn directions.

These are all a far cry from the simplicity of a link to maps.google.com. Wouldn't it benice if there was a maps.apple.com website providing maps access to anyone with aWeb browser? In fact, there is such a site, and sharing a location or directions from theOS X Maps application will include a link to it that looks something like this:

http://maps.apple.com/?q=40.911852,-73.254653&sspn=0.010284,0.023626&sll=40.911844,-73.254653

But don't expect to see a Google-Maps-like Web interface at maps.apple.com; it mere-ly redirects to the "best" available location: the Apple Maps app in iOS, the Maps ap-plication in Mavericks, and (embarrassingly) the Google Maps website if you're run-



ning a non-Apple OS or an older version of OS X.

It's a testament to Google's Web expertise that using Apple's native Maps applicationdoesn't feel appreciably more powerful or responsive than using Google Maps in amodern Web browser. And Google Maps has features like Street View for which Ap-ple still has no answer.

I'm glad OS X has reached feature parity with iOS in yet another area. The OS X Mapsapplication is perfectly adequate, even if it doesn't dazzle; we've seen these featuresbefore in iOS 6, after all. But Apple really needs to step up its mapping game if it everwants to catch up to Google.

Multiple displays

Twenty-five years ago (yikes), the Macintosh was known for its excellent built-in sup-port for multiple monitors. The Monitors control panel showed the relative sizes ofthe attached displays as well as their positions, which could be adjusted by dragging.During normal use, the mouse cursor would move smoothly from one display to an-other, crossing over at the edges where the monitors met.



The System 6 Monitors control panel: built-in support for multiple displaysin 1988.

The primary display was selected by dragging the representation of the menu barfrom one tiny screen to another. The system could even handle monitors with differ-ent color depths. Dragging a window so it was half on a 256-color display and half ona black-and-white display was a big nerd crowd-pleaser in the late 1980s, let me tellyou.

Fast-forward a few decades and the capabilities (and user interface) that the Macin-tosh pioneered are now taken for granted. But when it was the Mac's turn to playcatch-up two years ago with OS-level support for full-screen windows, the handlingof multiple displays came to the fore once again.

In Lion, triggering full-screen mode for a window caused all other attached displaysto be filled with the now-blessedly-banished linen texture. This behavior was especial-ly infuriating when using a projector as a secondary display. Click the full-screen wid-get on the window being projected and the entire room gets treated to a giant swathof gray linen. Smooth.

Mountain Lion offered a little relief, allowing windows to go full-screen on any dis-play—but still covering all the other screens with linen.

Mavericks finally sets things straight. Each attached display is now treated as a sepa-rate domain for full-screen windows. Mission Control gestures and keyboard short-cuts will now switch between the desktop and full-screen windows on the displaythat contains the cursor only, leaving all other displays untouched.

The price of this feature is the loss of the aforementioned nerd-impressing ability tohave windows that span multiple displays. In Mavericks, a window can span screenswhile being dragged, but it will appear partially transparent on the destination screenuntil the cursor touches the edge of the screen from which the window is beingdragged, at which point the opaqueness will switch sides. Releasing the window mid-drag leaves it visible only on the screen where it's opaque.

Mission Control now displays on all attached screens when activated, each screenshowing its own desktop and application windows. Windows (full-screen or other-wise) can be dragged between the separate Mission Control domains.



A second Mission Control domain on a second monitor; note the "Desktop2" item at the top.

These changes alone make Mavericks a must-have upgrade for some people—butwait, there's more. For as long as Macs have supported multiple monitors, peoplehave asked for a way to quickly access the menu bar from a non-primary display. Sev-eral third-party applications have provided this ability over the years. Mavericks fi-nally makes it official—and mandatory. The menu bar now appears on every attacheddisplay.

This feature finally provides a legitimate function for the ill-considered translucentmenu bar added to OS X five years ago: put an opaque menu bar on the screen withthe current input focus and use a translucent menu bar on all the other displays.

Unfortunately, Apple is still convinced that there's some value in allowing the desk-top background to impair the readability of the menu bar on the display with the cur-rently active application. In Mavericks, other displays get an even more (and differ-ently) translucent menu bar.



The translucent menu bar on the primary display.

The other, differently translucent menu bar on a secondary display.

The option to disable the translucent menu remains (in the Desktop & Screen Saverpreference pane). Using it creates the experience I want: opaque on the display I'm us-ing, translucent elsewhere.

Interestingly, since each full-screen window is tied to a display and has its own menubar (visible when the cursor hits the top of the screen), it's now possible to have twodifferent menu bars visible at once in OS X. Just use a non-full-screen window fromone application on one display, then press the mouse cursor against the top edge ofanother display containing a full-screen window from a different application. Truly,we are living in the future.

The Dock is also available on each display. When the Dock is positioned on the bot-tom of the screen, dragging the cursor to the bottom of a secondary display will causethe Dock to appear there (and disappear from the primary display). This feature is alittle finicky in practice, often requiring an extra bit of downward mouse-dragging ortrackpad swiping to trigger it.

AirPlay-compatible displays (e.g., your television set with a 2nd or 3rd generation Ap-ple TV attached) can now be used as full-fledged additional displays, instead of justmirroring the primary display. (AirPlay displays can also mirror any other attacheddisplay.) Like the existing AirPlay mirroring feature, this functionality is limited toMacs from early- to mid-2011 or later.



New AirPlay display options: extend, instead of just mirror.

Apple has made improved support for multiple displays one of the headline featuresof the Mavericks marketing campaign. For people who never use more than one mon-itor, that may seem silly. But the cumulative annoyance of the pre-Mavericks behaviorfor those of us who use multiple monitors on a regular basis should not be underesti-mated. Mavericks makes multiple monitors work the way we've all wanted them tofor years.

Well, perhaps not all of us. If you prefer the old behavior, uncheck the "Displays haveseparate Spaces" checkbox in the Mission Control preference pane. Doing so will alsorestore the ability to have windows that span more than one display. You know, forold times' sake.

Energy saving

Nine years ago, Apple sold more laptops than desktops for the first time. These days,Apple routinely sells three to four times more laptops than desktops. It seems strange,then, that Apple waited so long to release a version of OS X heavily focused on ex-tending battery life.

Back in the early 2000s, Apple's laptops compared favorably to contemporary Win-dows laptops in terms of battery life. Today, the bar has been raised—not by Win-



dows laptops, but by iOS devices, which now outsell Macs 10-to-1. The battery life ofthe iPad in particular has embarrassed Apple's heavier, more expensive Mac laptopsfrom the day it was introduced three years ago.

Apple has done a lot to reshape its Mac laptop hardware in the image of iOS devices.Moving parts were eliminated (optical discs, spinning hard drives); removable, self-contained parts were replaced with smaller, custom-fit equivalents (SSDs, batteries);and the number of chips on the logic board has steadily decreased (discrete GPU andnorth/south bridge chips replaced with integrated GPU and on-package PCH). All ofthis has led to increased battery life, with Apple's latest Haswell-based MacBook Airsfinally achieving run times comparable to the much smaller, lighter iPad.

Time to declare victory, right? Well, not quite. Yes, Apple's latest laptops can reach10+ hours of battery life… under the right circumstances. To understand the problem,consider the top energy consumers in a laptop: LCD, RAM, SSD, CPU, GPU. (We surelove our TLAs.) All of these components require some minimum amount of power torun. The display can be switched completely off, but at that point it's not doing theuser much good. The RAM must be refreshed every few dozen milliseconds, lest itlose all the data it contains. (Try not to think about it.)

The trouble isn't the minimum power required to keep things running, it's the differ-ence between the minimum and the potential maximum power consumed by the mostdemanding components of the system. When it comes to dynamic power range, noth-ing in a laptop beats the CPU/GPU combination (now both on the same die inHaswell). The chart below, used by Apple at WWDC to explain its energy-savingstrategy in Mavericks, shows some power usage numbers for a typical modern laptopCPU with an integrated GPU.



(The "Turbo" label refers to Intel's Turbo Boost feature that allows the CPU to runfaster than its rated clock speed as long as power and thermal limits allow it.)

That's a 60x range between idle and turbo. And make no mistake, a sustained powerdraw of 15 to 25 watts from the CPU alone will do terrible things to a new MacBookAir's 54-watt-hour battery. (Do the math.) So much for a "12-hour" battery life.

No other component of the system has such a huge range between idle and maximumpower combined with such a high maximum power level. A dimmed screen does notconsume 60 times less power than a bright one; laptop RAM (soldered to the logicboard in Apple's modern MacBooks, Air and Pro) and SSDs will never use 25 wattseven when running full-tilt.

Given all of this, the most effective software strategy for saving energy becomes clear:keep the CPU idle as much as possible.

This is not as ridiculous as it sounds. Even when you're actively using your Mac, theCPU is probably spending most of its time waiting for input. Let's say you're an amaz-ing typist and you're clacking away on the keyboard at 120 words per minute. That'sabout one keystroke every tenth of a second. In the time between each of your key-strokes, even the slowest 2013 MacBook Air has enough time to perform hundreds ofmillions of operations.

Of course, your typing is not the only thing happening on the system, nor is it themost stressful to the CPU. Perhaps a video is playing in another window; if you're adeveloper, Xcode may be compiling your code as you type in order to catch errors;maybe some e-mail just arrived and was processed by the Mail application; Spotlightwill get a chance to index each newly created or modified file; Time Machine may berunning in the background.

Here's a simplified representation of a hypothetical CPU workload.



That sure looks like a lot of idle time, right? But there's another wrinkle. Real CPUsdon't go from working to idle instantly. There's some transition time to account for. Itdoesn't take long, and the delay is getting smaller all the time, but it remains non-zero.

In practice, a modern Intel CPU can reactivate a clock-gated region of the chip in 10-15microseconds, and it may take hundreds of microseconds to restore the state of a corethat has been powered down entirely.

Look again at the scale on the x-axis of the chart above. It shows just 1 millisecond ofelapsed time. Even a ten-microsecond transition is going to show up on that graph.Let's add power state transition information to the chart (again, in a heavily simplifiedform).



Suddenly, the amount of truly idle time has decreased dramatically. When the gap be-tween units of work is small enough, the CPU doesn't get back to idle at all. All of thatgray area under the curves is waste, and there's a lot of it.

Now think back to the earlier examples of activities that might be using the CPU: pro-cessing keystrokes, playing video, compiling code, receiving e-mail, running backups,indexing files. Only some of this work has a hard deadline.

Things like audio and video playback may only need a small amount of CPU time,but they need it on a regular basis to prevent skipping or stuttering. Likewise, fasttypists want to see their keystrokes reflected on the screen as soon as possible. As foreverything else, there's definitely some wiggle room.

And remember, we're only considering a single millisecond of total time. With evenjust a little bit of tolerance for rescheduling, we can rearrange the work into a more ef-ficient form.



Ah, that's more like it! By coalescing the work into a contiguous burst of high activity,transitional waste has been cut to a bare minimum, and the amount of idle time hasbeen maximized. Even better, this strategy becomes more effective as CPU speed in-creases. All other things being equal, if the CPU can complete the same amount ofwork in less time, it can get back to its power-sipping idle state sooner. (Picture thered block in the chart above becoming narrower.) This is called the "race to sleep" phe-nomenon.

There's one final strategy to maximize CPU idle time. It's the obvious one: do less totalwork. Background tasks like backups or Spotlight indexing can be slowed down, butlike the laundry, they do eventually need to be done. Processing user input is un-avoidable. But there's a third kind of work that is pure waste.

Consider a progress bar in the Mail application, updated as it receives e-mail in thebackground. If Mail is not the front-most application right now, that progress barprobably doesn't need to update ten times per second. Maybe updating once a secondis enough. Or think of an animation running in a Web browser window that's entirelyobscured. That animation may not need to run at all.

A rule of thumb emerges: if it doesn't benefit the user, either immediately or in the fu-ture, do it less frequently; if possible, don't do it at all.

Energy-saving strategy summary

Let's recap. The CPU is one of the most power-hungry components in a Mac laptop,but it also has the largest range between its idle and maximum power usage. Maxi-



mizing CPU idle time is therefore an effective way to extend battery life.

Because components of the CPU take some time to transition to and from an idle state,doing work in contiguous chunks minimizes the number of these transitions and in-creases the total time that the CPU is idle.

Eliminating work that produces no immediate or lasting benefit to the user can reducethe total amount of work to be done.

Now, finally, let's see how Mavericks implements this strategy.

App Nap

App Nap is Apple's umbrella term for a suite of energy-saving policies applied to ap-plications in Mavericks. Like so many of the new technologies added to OS X over theyears, App Nap includes new APIs for developers to incorporate into their applica-tions. Apple is leading the way by using these APIs extensively in the applicationsand services that are part of Mavericks.

Unlike new technologies like sandboxing or Grand Central Dispatch, Apple is notcontent to wait for third-party developers to update their applications to use thesenew APIs. Applications running on Mavericks are eligible for App Nap by default.

The new Energy tab in the Activity Monitor application provides an overview ofprocesses' power usage over time, including a new App Nap column.



When an application is napping, its CPU and I/O priority is lowered, causing the ap-plication to do less total work. But what about moving the work that is done into con-tiguous chunks, as described in the previous section?

Moving boxes on charts is easy; the past, present, and future are all laid out beforeyou. Scheduling the actual work performed by real, running applications is quite a bitharder. Though the operating system can track the work done by each application, itcan't move new work backward in time to form contiguous chunks in the past. Thebest it can do is delay new work in the hopes of combining it to form contiguouschunks in the future.

Predicting future CPU usage is a tall order, but there's one kind of work that makesthe job easy: timers. Anything displayed on the screen that changes in response to thepassage of time (rather than just user input) likely has one or more timers behind it.This includes obvious things like the clock in the menu bar, the blinking text insertionpoint, or a throbbing default button in a dialog, but also less visible things like appli-cations that periodically pull information from the network (e.g., a stock ticker, newsreader, or Twitter client). And don't forget every use of the now-ubiquitous Core Ani-mation framework.



Timers throughout Mavericks are coalesced in order to realize the energy savings de-scribed earlier. Even a single application is likely to have many timers running simul-taneously. When all timers across the entire system are considered, there's ample op-portunity to align events and maximize uninterrupted runs of idle time.

Consider the three timers below, shown running at their natural intervals.

Given a little leeway to reschedule events, those timers might be coalesced as shownbelow.

When coalescing timers, Mavericks may delay events by around 100 milliseconds inorder to get them to align with other events. (Unlike the example images above,timers will never be fired early in Mavericks; they may only be delayed.) This delayshould be imperceptible to the user. In fact, in past releases of OS X, timers routinelyexperienced similar delays due to preemption from higher-priority processes or I/Otasks, or even just some other work happening on the same event loop. In Mavericks,the difference is that this delay is premeditated and purposeful instead of merely inci-dental.

Not all timers are created equal when it comes to conserving energy. High-frequencytimers are the biggest energy hogs, often firing many times a second, repeatedly wak-ing the CPU from its idle state. When App Nap is activated for an application, themaximum rate that any timer is allowed to fire is severely limited, requiring manyseconds between events.



App Nap Policy

Right about now, you may be worried that Mavericks is going to make your Mac feelslower by starving all your applications of resources. But remember that the goal ofApp Nap—and Mavericks as a whole—is to extend battery life, yes, but also to im-prove responsiveness.

Rather than picturing App Nap as an energy miser, throttling all your processes toconserve energy, think of it as a guardian, ensuring that whatever you're currently do-ing has access to as many system resources as possible. Success or failure comes downto the question of which applications should nap and when.

The policy in Mavericks is conservative. First, only normal Cocoa applications are eli-gible for App Nap. As mentioned earlier, this is true regardless of whether an applica-tion has been updated for Mavericks. The Cocoa framework itself makes several pri-vate system calls to tell the operating system that the process associated with an appli-cation is eligible for App Nap.

A new checkbox in the Finder's Get Info window allows the user to disable App Napentirely on a per-application basis—but only for applications that are not linkedagainst the OS X 10.9 SDK. Developers who use the Mavericks SDK are expected toexert more fine-grained control over how App Nap affects their applications by usingthe new App Nap API.

Though Cocoa applications are signed up for App Nap by default and must opt out ifthey don't want it, the existence of the aforementioned private system calls means thatany other kind of executable that is not a normal GUI Cocoa application is not eligiblefor App Nap.

In fact, Cocoa applications that are not "foreground" applications (i.e., that do nothave an icon in the Dock—see the LSBackgroundOnly or LSUIElement Info.plist keysfor examples) are also not eligible for App Nap. (There are other energy-saving strate-gies for background applications; more on those later.)

For all applications that are eligible for App Nap, Mavericks applies a set of heuristicsto determine when it's safe and appropriate to put an application down for a nap. Sev-eral factors influence this decision: application window visibility and drawing activi-ty, audio playback, user input event processing, and the use of the existing power as-



sertion APIs.

One of Apple's demos in the App Nap session at WWDC featured a Cocoa implemen-tation of the classic xeyes application. A pair of simply rendered eyeballs whose gazefollows the cursor hardly seems like an energy hog, but it's exactly these kinds of in-nocuous applications that can end up using far more than their fair share of systemresources. Xeyes must track the mouse cursor constantly, even when it's not the front-most application, and it must continually redraw its interface in response to thesemouse movements.

Sure enough, the new Energy Impact column in Activity Monitor—a composite, unit-less estimate of an application's energy usage over time—shows that a pair of mouse-tracking eyeballs can be surprisingly taxing. But with the default App Nap heuristics,dragging another window on top of the eyeballs, obscuring them completely, eventu-ally causes the application to nap and its Energy Impact to drop to zero.

The exact weighting of the factors that influence App Nap will no doubt change asMavericks matures. A completely hidden application is an easy call, but in the generalcase, it won't always be so simple for the OS to understand which activities are impor-tant to the user. When Mavericks is forced to guess, it tends to err on the side of leav-ing the application unmolested. But Apple would like it if the operating system didn'thave to guess, which is why it provides several new APIs that allow developers totune their applications for energy efficiency.

But before considering those, it's worth noting that there's a lot that developers canand should do to make their applications better citizens even when they're not nap-ping.

Energy best practices

One way to implement the xeyes demo application described earlier would be to peri-odically poll for the position of the mouse and then update the eyeball graphics to re-flect the new cursor position. For smooth animation, this polling would have to bedone at least 20 to 30 times a second.

Unfortunately, polling is one of the least efficient ways to accomplish this task. Evenwhen the cursor isn't moving at all, the application is checking and rechecking themouse position many times a second—and possibly redrawing the eyeballs each timeif the developer isn't storing the previous state for comparison purposes.



OS X offers a much more energy-efficient global event monitoring facility. (This is notnew in Mavericks.) The operating system is already tracking the cursor; there's noneed for individual applications to do so as well. The application merely needs to reg-ister its interest in the cursor position and the OS will notify it when the positionchanges. No polling needed. This means that the xeyes application's CPU usage candrop to nearly zero when the cursor isn't moving, even when its window is not ob-scured and the application is not napping.

This is the ideal: when an application isn't doing anything useful, its CPU usageshould be as close to zero as possible. To achieve this, Apple discourages all forms ofpolling. Nearly every interesting event on the system can be delivered on demand tointerested applications: FSEvents for file system changes; GCD's dispatch sources forfile and network I/O, process creation and destruction, and signals; semaphores andlocks for process synchronization.

Once an application has excised all forms of polling, it's time to consider what else canbe done in Mavericks to become even more efficient.

App Nap API

As we've seen, the App Nap heuristics can do a reasonable job of detecting applica-tions that aren't providing useful feedback to the user and then applying the App Napenergy-limiting policies to them. But this process is not perfect, and, more important-ly, an unmodified application will be unaware that it's happening.

Rather than waiting for App Nap to be applied by the system (which in practice cantake around ten seconds), applications can use the new App Nap APIs to take mattersinto their own hands.

Visibility

The first set of APIs allows applications to detect when they're occluded and then takeaction themselves. An application is considered occluded if it has no visible windows.(The menu bar, technically a window, doesn't count unless it contains a status baricon created by the application.) If even a sliver of a window is showing, the applica-tion is considered visible. Windows that are minified to the Dock are not consideredvisible.



Application occlusion state is represented by a bit field (hey, they're not just for the1980s!), with only one bit used right now to represent two states: completely visibleand completely hidden. It seems like Apple has plans to make this API more granularin the future.

There's also an occlusion API for individual windows. The same rules apply: if anypart of a window is showing, it's considered visible. And as with the application oc-clusion API, window visibility is currently represented by a bit field with only one bitused.

An application can use these visibility APIs to immediately discontinue expensive op-erations that can no longer benefit the user when some or all of its windows are hid-den. Crucially, the application can also immediately resume those activities the instantvisibility is restored.

The energy savings provided by completely discontinuing work when possible areeven more dramatic than merely doing work more slowly due to the limitations auto-matically imposed by App Nap. This brings applications ever closer to the ideal of do-ing zero work and using no system resources when idle or ignored.

Timer tolerance

We've already seen how Mavericks will attempt to coalesce timer events to reduce thenumber of transitions to and from the CPU's idle state, how App Nap can limit themaximum rate at which timers are allowed to fire when an application is napping,and how periodic polling using a timer is an inefficient way to detect changes else-where in the system.

But there are instances where strictly time-based operations are part of an applica-tion's core functionality (e.g., a reminder application, an RSS reader, or Twitter client).In cases where the use of timers may be appropriate, Mavericks provides a way to ex-press a time-shifting tolerance for each explicitly created timer beyond the standard100-millisecond tolerance applied to all timers by default.

If an application has a timer that fires every 10 seconds, perhaps a tolerance of onesecond or more is appropriate. The more timers on the system with large tolerancevalues, the more flexibility Mavericks has when coalescing timer events. Developersare strongly encouraged to apply larger tolerance values—10 percent of the timer in-



terval is suggested—in cases where millisecond precision is unnecessary.

Timers can also be explicitly exempted from App Nap's rate limiting. Apple cautionsthat such timers should be rare, perhaps used only when an application interacts witha hardware device or network with specific latency demands. These "strict" timers stillaccept a tolerance value in milliseconds, though, and a value of zero is strongly dis-couraged.

User activities

The new user activities API provides a way for applications to improve the system'sApp Nap heuristics. With it, applications can tell the system the nature of the workthey're performing, including a descriptive string that may show up in system logsand other diagnostic messages (e.g., in the output of the pmset -g assertionscommand).

The most common type of activity is "user-initiated," meaning any task performed asa result of direct user action (e.g., clicking a button, selecting a menu item). A variantof this activity type explicitly requests that the Mac not be allowed to go to sleep forthe duration of the activity.

There's also a "background" activity type that's meant to be used for maintenancetasks and other operations that are not time-sensitive. Background tasks have a lowerCPU and I/O priority to prevent them from contending with user-initiated tasks inthe same application.

Activity type options can be mixed with any activity type to modify its meaning: a "la-tency-sensitive" option for tasks that can't afford to be unduly delayed; options to dis-able display or system sleep; and options to disable Sudden Termination or Automat-ic Termination.

Many of these options are just nicer front-ends to the existing power assertions API,but the user activities wrapper makes them much more convenient to use from a Co-coa application while also making it less likely that a developer will forget to release apower assertion.

A single application can have multiple types of activities running at once, and AppNap will take all of them into consideration when deciding when it's time for an ap-



plication to take a nap.

Energy shaming

Mavericks has one final energy-saving trick up its sleeve. Except in extreme cases, ap-plications that burn CPU cycles needlessly usually do so without drawing attention tothemselves. When battery life suffers, everyone's ready to blame Flash animationsrunning in browser windows or graphics-intensive games, but the real culprit may bethe constant low-level waste generated by dozens of seemingly innocent applications:Twitter clients, text editors, status items in the menu bar, even preference panes.

To help developers determine if their application is wasting energy, the new versionof Xcode includes an extensive set of tools for measuring and displaying energy usageover time.

Xcode 5's energy impact tools.

But perhaps most importantly, the battery status menu in Mavericks now includes a"hall of shame" section that lists applications that are currently using "significant ener-gy" on the system.



The battery status menu now calls out energy-hogging applications.

I can imagine Mac developers everywhere cringing at the thought of the e-mailthey're going to receive from users when their application shows up as an energy hog.Some applications need "significant energy" to do the task they're designed to do.

Presumably, Apple will try to avoid reporting such activities as wasteful, but thatmay be unavoidable. And it's pretty easy to get some of Apple's own applications toappear in the menu, as shown in the screenshot above. Selecting an application fromthe menu launches Activity Monitor, switches to the Energy tab, and highlights theguilty application.

Despite the customer support noise that this feature will inevitably create, it may verywell be one of the most important energy-saving features in Mavericks. Apple hasbeen preaching the doctrine of efficient resource usage on OS X for years now. Butsilent, parasitic energy loss due to a statistical haze of slightly inefficient idle applica-tions is not a good motivator for developer action.

With Mavericks, Apple has forced the issue. Applications will be subject to App Napif developers do nothing; energy hogs will be reported in a place that's easily discov-erable by the average Mac user. This combination of factors should finally result insome real action for actively developed Mac applications. (The best developers havealready improved their applications' energy efficiency for Mavericks.) It might evencause people to finally abandon applications that haven't been updated in years, oncetheir battery-sucking ways are revealed.

Background tasks

For many years now, daemon processes in OS X have been managed by launchd, Ap-ple's all-singing, all-dancing background task manager. A surprising number of OS



services are implemented as daemon processes that applications communicate withvia IPC (usually indirectly, through a framework).

In Mavericks, these services run with a reduced priority, allowing GUI applications totake precedence when there's contention for CPU cycles or I/O. But when a GUI ap-plication makes a request to one of these services, the service process's priority is"boosted" for the duration of the request, allowing it to quickly service the request andthen go back to its reduced-priority state.

Background jobs created by the user or by third-party applications can also adopt thispriority-boosting behavior by setting a new ProcessType property in the descrip-tion of the job. Apple categorizes the possible ProcessType values by how muchthey're allowed to contend with "normal" foreground GUI applications. Here's the list.

Process Type Contention BehaviorAdaptive Contend with normal applications only when doing work on their behalfBackground Never contend with normal applicationsInteractive Always contend with normal applicationsStandard Default behavior in Mountain Lion and earlier

Adaptive jobs also have the ability to maintain their priority boost even after the replyhas been sent to the requesting application (e.g., if the work it's doing on behalf of theapplication is asynchronous, it might send a reply even before starting the actualwork).

Centralized task scheduling

In OS X, there are many tasks that need to be done "eventually" but are not particular-ly sensitive to delays. New volumes must have their Spotlight indexes created. Long-running services that create many temporary files as part of their work should take abreak every once in a while and clean up their messes. Apple's servers need to be con-tacted periodically to check for updated versions of applications and the OS itself.

The lack of urgency for these tasks doesn't mean that any time is as good as any other.For example, the experience of using a fresh installation of OS X has been slightlydampened for years by the Spotlight indexing process that often kicks off immediate-ly upon login. And if your MacBook is down to its last 15 minutes of battery life, that'sdefinitely not when you want it to grind away at your disk checking if you have thelatest versions of all the applications you've purchased from the Mac App Store.



Mavericks breaks these kinds of tasks into two categories, once again defined by theircontention behavior.

Activity Type Contention BehaviorMaintenance May be interrupted by any normal user activityUtility May be interrupted by resource shortages (e.g., RAM, CPU cycles)

For example, the Software Update job in Mavericks is declared to be a "Maintenance"task, meaning it will try to run when you're not actively using your Mac. Time Ma-chine's backup process, on the other hand, is marked as a "Utility" task, meaning itwill run as long as there's no undue contention for the resources it needs.

Individual tasks can further narrow the conditions under which they will run by spec-ifying the following criteria:

Requirement DescriptionAllowBattery

Allow the task to run when using battery power. The default value is false for"Maintenance" tasks but true for "Utility" tasks.

RequireScreen Sleep Require the primary screen to be in sleep mode. The default value is false.

Battery LevelRequire a specified minimum battery level percentage. A default (presumablylow) minimum battery level is chosen by the system to preserve the last shreds ofbattery power.

RequireHDDSpinning

The task should only be performed while the hard disk drive is spinning. In otherwords, don't spin up the hard drive just to perform this task. (SSDs are alwaysconsidered to be spinning.) The default value is false.

Applications can programmatically create these kinds of background tasks, specifyingthe activity type, the required conditions, and the interval between runs (with an op-tional grace period akin to the adjustable timer tolerance). These tasks are persistentacross launches of the applications and reboots of the system. If a task is interrupted(e.g., due to user activity, the removal of AC power, a battery level drop, etc.) it willbe resumed automatically by the system when possible.

If you're curious about the background tasks that are part of OS X, look in the /Sys‐tem/Library/LaunchDaemons and /System/Library/LaunchAgents directo-ries. There you will find a collection of launchd property list files. In Mavericks, lookfor the com.apple.xpc.activity key in the property list to see if the job is usingany of the new task scheduling restrictions described above.

Compressed memory



Apple has historically had a bad reputation among tech-savvy Mac users for includ-ing too little RAM in its default hardware configurations. Constantly being on theragged edge of available RAM can severely affect the experience of using a Mac. Foryears, I've practically begged everyone I know who's getting a Mac to opt for morethan the standard amount of RAM. Sure, people say they'll just be using it for "lightWeb browsing and e-mail," but even casual usage of Safari, Mail, iPhoto, and iMoviecan translate into some serious RAM usage.

What is RAM for if not to be used? Ah, but as the aforementioned tech-savvy Macusers know all too well, when OS X runs out of RAM, it starts copying data fromRAM to swap files on disk. If that same data is needed again soon, it has to be readback from disk. If RAM is still tight, some other data in memory has to be evictedfrom RAM and written to disk to make room for the incoming data. If this processkeeps repeating itself, you have what's known as "thrashing," where the system isspending most of its time ferrying data between RAM and disk.

Data spilling over from RAM to disk may not seem like such a big deal if you don'trecall exactly how much longer it takes to get information from disk than from RAM.Reminder: it takes hundreds of thousands of times longer to read data from a spinninghard disk than from RAM. SSDs are much faster than spinning disks, but they're stillhundreds of times slower than RAM.

This performance cliff is why iOS was designed to work without a swap file. It's alsowhy iOS ruthlessly kills applications that are not currently being used. Though OS X'sautomatic termination feature makes some moves in that direction, swap is here tostay on the Mac (for now). But avoiding it is still a big, big win.

This isn't just a performance issue, however. Performance and energy consumptionare inextricably linked. Recall the concept of "race to sleep." The faster a task can beaccomplished, the sooner the Mac can get back to its low-power idle state. SSDs maynot have any heads to move or platters to spin up, but they're still hundreds of timesslower than RAM—and time is energy.

One way to avoid filling RAM is to run fewer applications. Automatic terminationhelps with that. Another solution is to reduce the amount of RAM in use by the appli-cations that are running.

For years, OS X has included APIs that allow applications to designate regions of



memory as "purgeable." For example, an application might cache the results of someexpensive operation in a purgeable memory region. If the OS needs more RAM, it'sfree to take the memory used by that cache and use it for another purpose. If the ap-plication that created the cache needs that information again, it will just have to re-compute it.

You might think that no application developer would ever willingly mark any memo-ry as purgeable. Why volunteer to have your memory reclaimed by the OS? But theOS will not be denied; it is going to reclaim RAM no matter what. Purgeable memoryregions allow developers to choose which memory gets reclaimed first from their ap-plications.

If RAM is still scarce, the OS has its own caches and purgeable regions of memory toharvest. Memory-mapped files can go back to living only on the disk. In-memorycaches of file system data and metadata can be expunged.

When every application has been squeezed and every OS cache has been purged andthe demand for RAM still hasn't been met, that's when previous versions of OS Xwould have no choice but to start hitting the swap file.

In Mavericks, the OS has one more option before it has to resort to swapping: com-pressed memory. Mavericks will find the least-recently-used data in memory andcompress it, usually to about half its original size. Et voilà, more free memory.

Like the HFS+ compression feature introduced in Snow Leopard, compressed memo-ry trades relatively abundant CPU cycles for decreased disk I/O. The compressionand decompression process is extremely fast, using the WKdm compression algo-rithm, and it will run in parallel, taking advantage of multiple CPU cores.

Intuitively, a multi-core CPU grinding away compressing data in RAM does not seemlike a winning strategy to save energy. But our intuition is often wrong when it comesto real-world energy use on modern hardware. Remember, it's a race to sleep! Avoid-ing shuttling data between RAM and that hundreds-of-times-slower-than-RAM SSDis a big win as long as the compression task can be completed in a fraction of the timeit would take to access the SSD. It can be, and it is.

In fact, Mavericks seems fairly terrified of the swap file. Here's what Activity Moni-tor's memory summary looks like when the system is just about at the limit of itsRAM capacity.



15.99GB out of 16GB of RAM in use, and yet Mavericks still keeps its cool,holding the line at 0 bytes of swap.

Ask for more RAM in this situation and Mavericks goes after its own file cache whilestill holding the line on swap. Ask for way more RAM—gigabytes more—and thememory compression starts. Eventually, the use of swap is unavoidable. But just lookat how far Mavericks can go before it finally resorts to swapping to disk.

Mavericks with a heroic 8.54GB of compressed memory, finally dipping itstoe into a few megabytes of swap.

Put Mountain Lion under the same kind of memory pressure and things go southquickly. As soon as RAM is exhausted, Mountain Lion has no choice but to startswapping to disk, driving performance off a cliff. Mavericks doesn't even touch swapuntil it's squeezed several gigabytes more data into RAM than the Mountain Lion sys-tem.

Memory compression is a triple play for Mavericks. It's a performance win; compress-ing and decompressing data in RAM is much faster than reading from and writing todisk, even an SSD. It's an energy win; the less time spent moving data between RAMand disk, the more time the system can spend in its idle state. And finally, it's a capa-bility win; Mavericks can handle much more demanding workloads than previousversions of OS X before crying uncle.

Battery benchmarks

Though applications will have to be updated to take full advantage of the energy-sav-



ing enhancements in Mavericks, Apple has had some time to practice what it preachesand has updated the applications and background tasks that come bundled with theOS. It stands to reason, then, that a clean installation of Mavericks running only bun-dled applications should exhibit better battery life than those same applications run-ning on Mountain Lion.

To test this, I created a light Web browsing and text-editing automation script specifi-cally designed to allow applications to remain idle for several seconds between eachaction. Briefly running the test on Mavericks and inspecting the running applicationsin Activity Monitor revealed that some applications do indeed enter App Nap be-tween the spurts of automated activity.

I also installed Flash Player in both Mavericks and Mountain Lion, and I intentionallychose some websites that include Flash. These tests were run on the GM build of Mav-ericks and OS X 10.8.5 with all updates (as of October 4, 2013) applied.

The first test system was my venerable pre-unibody 2007 MacBook Pro, so the num-bers obviously don't reflect the modern experience of using a Mac laptop. The Core 2Duo CPU and discrete GPU in this Mac also lack the amazing low-power idle capabil-ities of the latest Haswell-based MacBook Airs. Can Mavericks do anything at all forthis old clunker? You bet it can.

Yes, kids, this is what battery life was like in the days of optical drives, re-movable batteries, and 65nm CPUs.

That's a whopping 25 percent increase in battery life for Mavericks on this extremelyold laptop. The increase on modern hardware like the new MacBook Air can be evenmore impressive.



As if the new MacBook Air's battery life wasn't obscene enough already.

The MacBook Air exhibited widely varying results for Mountain Lion in repeated exe-cutions of this test, ranging from a low of just over 9 hours to a high of nearly 14hours. The Mavericks results were more consistent, but they still varied by up to anhour and a half in either direction.

All of this is to say that the MacBook Air's impressive 30 percent increase in batterylife shown above probably depends heavily on many factors outside your control. Isuspect the aggressiveness of the auto-playing Flash ads that happen to be on specificwebsites on a particular day may partly explain the huge variability in Mountain Li-on's numbers. Some of the lower-scoring Mountain Lion trials may have also had thebad luck to coincide with energy-intensive periodic jobs—jobs that are preventedfrom running on Mavericks due to AC power or battery-level restrictions as part ofcentralized task scheduling.

But even on Mountain Lion's best day, the increase in battery life for Mavericks on thenew MacBook Air is nothing to sneeze at, typically providing an extra two hours ofwork time in our tests. The next time you're about to run out of juice on your Mac-Book, think about how much you'd pay to put an extra hour or two back on the clock.

These tests may or may not be representative of how you use your Mac, but regard-less, it's clear that Apple's efforts have not been in vain. Mavericks really does con-sume less energy than Mountain Lion when performing the same tasks.

Energy summary

Conserving energy is not sexy. In the technology world, sexy usually means more,better, faster. Within the hardware limits set by the battery capacity and the energyconsumption of the system components, the only way to run longer is to do less work.



Ascetic computing just doesn't sound like fun. How many pre-WWDC OS X 10.9 wishlist stories in the tech press even mentioned battery life at all?

And yet we all find big increases in battery life attractive, sometimes even revelatory,once we experience them. New MacBook Air owners have been giddily posting pic-tures of their battery status menu and explaining how it has changed their habits and,in some tiny way, their lives.

The iPad introduction had a similar effect. Very little of the hype before the originaliPad was released was about long battery life, but these days it's routinely recognizedas one of the most important features of the product, even by iPad skeptics.

There's sexy and then there's the stuff that makes people fall in love with products forthe long haul. By now, Tim Cook's emphasis on what he calls "customer sat" is welldocumented. When viewed through the lens of customer satisfaction, the focus onbattery life in Mavericks is the first step down what will undoubtedly be a long andfruitful road for OS X.

It will be a long road for everyone. Apple can only do so much by changing its ownapplications and the OS itself. The universal application of App Nap shows that Ap-ple is more willing to be aggressive about energy consumption than it has been aboutother OS enhancements over the years, but third-party applications will have to beupdated—or abandoned—to realize the full potential of these new policies and tech-nologies.

Apple's vision of the hypermiling OS X of the future is attractive. Even setting asidethe advantages of longer battery life, the fervor with which Mavericks attempts toshun all work except that which I, the user, am directly requesting at this particularmoment is heartening. A Mac that drops everything to service my immediate needs isa better Mac, even when it's plugged into a power outlet.

Hardware changes will probably always yield more dramatic energy savings thanany OS update, but software algorithms and policies are what lead to improved re-sponsiveness. One day, I hope to look back on the experience of Spotlight, Time Ma-chine, and Software Update swamping my system while I try to do useful work thesame way I look back on being locked out of my Mac while a Finder copy operationwas in progress: not particularly fondly and from a great distance.



Responsive scrolling

When Mac OS X 10.0 was released, it was dog-slow. To give just one example, startingwith version 10.0 and continuing for release after release, there was a section of my re-views dedicated to the performance of window resizing in OS X. Outsiders mightimagine that such mundane details would be beneath the attention of Apple and itscustomers. We know better.

Mac OS X's user-interface responsiveness was just plain unacceptable back then. Butthere's no endpoint when it comes to refinement, no mythical destination beyondwhich further improvement is pointless. In keeping with that spirit, Mavericks in-cludes new APIs for improving the performance and responsiveness of scrolling.

Yes, scrolling. You may be thinking to yourself, what's wrong with the way scrollingworks in Mountain Lion? It's true, OS X has always been pretty good at scrollingopaque content. And since the advent of Quartz Extreme over a decade ago, OS X caneven slide sheets of transparent content past each other with aplomb. But there arestill limitations inherent in the current approach to scrolling views in OS X.

Picture a long document as an imaginary vertical stripe that extends several feetabove and below the screen. An application window frames only a small portion ofthe document.



Safari showing a portion of a longer webpage with the scrollable content vi-sualized above and below.

Traditionally, the visible region is also the only region of the document that's actuallydrawn by the application. After all, why waste time drawing content that's not visi-ble?

Scrolling the window causes new parts of the document to come into view. Each timethat happens, the application must draw the content to fill the newly visible region.This cycle of moving the viewport and then asking the application to fill the areathat's been revealed means that scrolling performance is limited by the speed that theapplication can draw newly revealed content.



The new responsive scrolling API in Mavericks takes advantage of times when theuser is idle to ask the application to draw small regions of the content that are not cur-rently visible ("overdraw"), starting with the areas directly adjacent to the existingviewport and extending outward.

This continues until the system decides it has sufficient overdraw available to handlefuture scrolling events. This decision takes into account available memory and—youguessed it—the energy consumed by these speculative drawing excursions. The appli-cation itself can also tell the system that it would prefer not to produce any more over-draw (e.g., if doing so is computationally expensive or consumes a lot of memory) orif it would like to draw slightly more than the requested area (e.g., if the requested re-gion intersects a subview that has to be instantiated in its entirety anyway).

The memory consumed by these overdraw regions is marked as purgeable, allowingthe OS to reclaim that memory if RAM starts to fill up. This memory can be reclaimedwithout even waking the application if it happens to be in App Nap.

Responsive scrolling also alters the traditional arrangement for handling scrollingevents. Rather than processing scrolling events on the main thread, responsivescrolling spawns a background thread for tracking user input (i.e., dragging on atrackpad or swiping a Magic Mouse). This background tracking thread will actuallychange the visible region of the view in response to scroll events. As long as there'ssufficient overdraw available, it can do this at a smooth 60 frames per second withoutdisturbing the application's main thread and without delaying the main event loop.

The main thread will be notified of the change and will synchronize its internal state.During an ongoing scrolling event, the synchronization process will also initiate moreoverdraw in the direction of the scrolling, sized partly based on the scrolling speed,anticipating the future needs of the background tracking thread.

It's essentially a race between the available overdraw and the user's scrolling speed. Ifthe user scrolls fast enough to outpace the generation of more overdraw, the systemreverts to the traditional pre-Mavericks scrolling behavior, with each newly revealedregion being drawn on demand.

Applications that are built against the OS X 10.9 SDK don't have to do anything spe-cial to enable responsive scrolling, though they may want to implement many of thenew callback APIs to be notified when it's happening.



A side-by-side comparison of scrolling in Mountain Lion and Mavericks reveals a per-ceptible improvement in smoothness. It feels a bit more like scrolling in iOS, wherethe content feels glued to your finger. The difference is subtle enough that some mightquestion the wisdom of this change. I do not. Small changes add up over time, eventu-ally bringing us to unexpected new places.

Furthermore, any change that adds another thread of execution has a bright future inour world of ever-multiplying CPU cores. This small step toward multithreading inOS X, like the many others that have come before it, is interesting in light of the histo-ry of OS X.

For a brief moment in 1996, it seemed like Apple might purchase Be Inc. and useBeOS as the basis of its new, modern OS. BeOS was ahead of its time in many ways,including its pervasive use of multithreading in the GUI. NeXTSTEP, with its single-threaded event processing and drawing, seemed positively antediluvian in compari-son.

Requiring a separate thread for each part of the user interface makes for a responsivesystem that can easily take advantage of multiple CPU cores, but it can also causeproblems by forcing programmers to deal with thorny synchronization issues andrace conditions in even the simplest applications.

Here we are, sixteen years later, and the OS that NeXT built is growing into its ownmulti-core shoes nicely, without any radical upheavals along the way. Small changesadd up.

iCloud Core Data

It's been a rough year for iCloud—part of it, anyway. iCloud is an umbrella term en-compassing many services and technologies. Three of them related to data storagewere described in last year's Mountain Lion review: Key Value Storage, iCloud Docu-ment Storage, and iCloud Core Data. (Core Data dates back to 2005, but its integrationwith iCloud is less than two years old.)

Here's what I wrote about these iCloud data storage APIs last year:

The number of ways things can go terribly wrong for iCloud-enabled appli-cations is astronomical. Apple has done a commendable job of creating theiCloud data storage APIs and the back-end service itself, but even if we as-



sume these things have zero bugs, it's still up to application developers touse these new APIs correctly.

That turned out to be an optimistic assessment. Though Key Value Storage andiCloud Document Storage have shaken out in the expected manner, iCloud Core Datahas fared far worse. Over the past year, developer after developer has come forwardto declare that there is no "correct" way to use Core Data with iCloud. It simply can-not be used to reliably perform its promised functions.

Rich Siegel of Bare Bones Software, creator of the venerable BBEdit text editor and a25-year veteran Mac developer, provided the most thorough technical explanation ofthe issues involved. Abandonment of iCloud Core Data eventually took the shape of afull-fledged movement among Mac developers big and small, leaving in its wake frus-trated customers, lost revenue, and a mad scramble to find viable alternativesolutions.

Apple comes into Mavericks suitably chastened on this front. Its goal for iCloud CoreData: make it work for developers. This entails more than just fixing bugs. iCloudCore Data in Mavericks includes new functionality and new APIs.

The Fallback Store, a local Core Data database that applications can use when theiCloud Core Data database is unavailable, is now managed entirely by the iCloudCore Data framework. Previously, developers had to manage the Fallback Store them-selves, juggling it and the "real" data store manually for each iCloud account. Thiswas further complicated by Apple's recommendation that the Fallback Store be storedin the iCloud container, which gets deleted automatically when the user disablesiCloud or switches iCloud accounts (e.g., by changing settings in the iCloud prefer-ence pane while an iCloud-enabled account is running). Apple now recommends thatdevelopers store an application's Core Data database somewhere outside the iCloudcontainer.

Moving Fallback Store management into the framework also simplifies the process ofchanging iCloud accounts. Previously, developers had to listen for an identity changenotification and then manually shuffle their data stores, including any Fallback Stores,removing the existing data stores and adding the new ones. In Mavericks, the iCloudCore Data framework does all the data store shuffling behind the scenes. Applicationsare notified only when the new data store is about to be swapped in, at which pointthey have a final chance to save any changes to the existing data store. Applications



receive another notification when the swap is complete.

Core Data's origin as a local data storage framework is reflected in its API. Things likechanging the data store in response to an iCloud account change used to be entirelysynchronous. While the application was removing the old data store and creating thenew one, the user would just have to wait. The wait wasn't long when everything wason a local disk. Adding a network service like iCloud to the mix changed the rules.Developers have reported seeing delays of up to 25 minutes when initializing theiCloud Core Data stack.

In Mavericks, iCloud Core Data setup is asynchronous. The method call to set up anew data store always returns immediately. If the iCloud data store is not immediate-ly available, the application will transparently use the Fallback Store instead. Whenthe iCloud data store is finally available, the Core Data framework will automaticallyintegrate the local changes made to the Fallback Store and then swap in the iClouddata store.

Finally, Apple has added some desperately needed debugging tools to give develop-ers more visibility into the inner workings of the iCloud Core Data system. The addi-tions range from more verbose console log messages all the way up to a dedicatedXcode debugging pane showing graphs and real-time information about data storechanges as they happen.

There are many more iCloud Core Data changes in the same vein as those describedabove. Operations that previously took too long have either been made asynchronousor eliminated. Tasks that previously had to be performed manually are now automat-ed. Developer tools have been improved. And all of these changes apply to iOS 7 aswell as Mavericks, with the added bonus that Mac-to-iOS iCloud Core Data syncingcan now be tested completely on a single Mac using the iOS simulator.

A matter of trust

After this past year of iCloud Core Data woes, the last slide of Apple's WWDC presen-tation on the topic should have said something like, "Oh yeah, and all the stuff we justdescribed will actually work this time." The best-case scenario is that all of thesechanges do work as advertised, and iCloud Core Data finally becomes a viable tech-nology for Mac developers. But even if that turns out to be the case, the developerswho spent the past year banging their heads against iCloud Core Data and subse-



quently rewriting their applications to work with a different back end are unlikely toleap at the opportunity to rip out those changes and switch back to the newly updatediCloud Core Data framework.

Normally, problems like this are confined to the world of developers. But the iCloudCore Data situation has gotten so bad that the issue has spilled over into the consumerrealm. When applications are delayed or promised sync features never materialize,customers demand answers. Fairly or not, application developers themselves oftenbear the brunt of the blame for these failures. Ironically, this leads developers towarda decidedly Apple-like mindset: don't rely on technologies you don't own or controlfor the most important features of your products. Getting these developers to recon-sider iCloud Core Data will not be easy.

Apple does have a few factors in its favor, however. Mac and iOS users get iCloud ac-counts for free and are logged into those accounts by default. "Free and logged in bydefault" is an extremely powerful combination when it comes to user experience. Cus-tomers don't want to sign up for—let alone pay for—individual syncing accounts foreach application they use. So while developers that were burned by iCloud Core Dataare justifiably wary of Apple's promises, the siren song of platform integration mayslowly pull them back to Apple's cloud.

Sprite Kit

Last year, Apple introduced Scene Kit, an OS X framework that did for 3D what CoreAnimation did for 2D animation: made it accessible to programmers who would oth-erwise run screaming from any mention of OpenGL or GPU-accelerated drawingcode.

Despite my enthusiasm for Scene Kit, it hasn't exactly set the Mac development worldon fire in the short year since its introduction. Off the top of my head, I can think ofonly one prominent Mac application that has integrated Scene Kit: Delicious Library3.



Delicious Library 3 uses Scene Kit to render three-dimensional items on itsvirtual shelves. Even the highlight is 3D.

I think its use of 3D to give some extra heft and sparkle to shelved items is extremelyrestrained and tasteful, but I've also heard the opposite opinion expressed. Perhaps3D models are more polarizing than 2D animations.

While it's possible to write a 3D game using Scene Kit, that isn't the goal of the frame-work. It's meant to help developers of regular Mac applications integrate 3D modelsand effects. Whether or not you believe that's a good idea, I think Delicious Library 3proves that Scene Kit has achieved its goal.

Mavericks includes a framework that's clearly part of the same family tree: Sprite Kit.I'm not sure which project was started first within Apple, but I did notice that SpriteKit got the "SK" class name prefix while Scene Kit was stuck with "SCN."

A sprite is a 2D image that can be placed and manipulated independently in a largerscene. If you've ever played a game on the original Nintendo Entertainment System,you've seen sprites in action. All the player characters, items, and enemies movingaround the screen are sprites.

Sprite Kit—you guessed it—makes it easy for Mac developers to integrate 2D sprites



into their applications. But wait, doesn't Core Animation already cover the same terri-tory? Not quite. While Core Animation and Scene Kit are both aimed at normal appli-cations, Sprite Kit is explicitly designed for games.

Games have very different requirements than normal applications. While an applica-tion might have an animation to punctuate a particular transition, games are runninganimations constantly. Games are also likely to have many more animated elementson the screen simultaneously. And unlike a sheet that slides down or a dialog box thatfades in and out, animated elements in games are expected to interact with each other.

Sprite Kit provides a complete set of tools for building a 2D game. It has a physics en-gine with collision detection to handle sprite interactions. Sprites can be scaled anddistorted, and they can have Core Image filters and particle effects applied to them.

There's a ray casting system for game mechanics based on line-of-sight, and methodsfor drawing vector shapes and text into a scene. Sprite Kit can even turn video into asprite, with all the same effects, transformations, and physics as a normal sprite. All ofthis functionality is provided through a pleasantly abstracted Objective-C API that's afar cry from the typical low-level C/C++ game engine code.

Recognizing that writing code is only a small part of game development, Apple hastaken the extra step of adding Sprite-Kit-specific features to its Xcode IDE. Xcode willautomatically combine individual sprite image files into larger, more efficient textureatlases. An integrated particle editor makes creating and adjusting particle effects afun, visual experience instead of a frustrating exercise of adjusting parameters and re-compiling.



Sprite Kit particle emitters can be created and edited right in Xcode usingthis real-time visual interface.

Finally, in case it doesn't go without saying, Sprite Kit works on both OS X and iOS.Not even Apple is foolish enough to create a framework this extensive for the solepurpose of creating 2D games for the Mac.

Seasoned game developers may turn up their noses at the build-your-own-2D-gametoolkit Apple has provided in Sprite Kit. Perhaps they've already got their own spriteengines written in C or C++ and their own asset pipelines that are part of a largermulti-platform game development effort.

But for a small team that wants to make a great iOS game first and foremost, SpriteKit gives them a huge leg up. As a bonus, if they code carefully, they'll get a Mac ver-sion of the same game almost for free.

And for any of those aforementioned seasoned game developers who happen to havean Apple developer account, I dare you to watch WWDC session 502, Introduction toSprite Kit, and not come away at least slightly impressed by how easy Apple hasmade it to create a high-quality Mac and iOS sprite-based game.

Scene Kit was the biggest surprise of last year's WWDC for me—a fun, impressiveframework that no one saw coming. Sprite Kit was a bit more predictable, but no less



impressive. I hope it's more widely adopted than its slightly older cousin.

Grab bag

Though Apple still hasn't given up on counting the new features in each major releaseof OS X, the webpage listing the new features in Mavericks is a freeform affair thatshuns numbered lists the way iOS device marketing shuns RAM specs. As always, mylist contains the handful of changes that piqued my interest.

System Preferences

Preference panes are big in Mavericks—literally. Preference icons are 25 percent larg-er (40 x 40 points) in Mavericks than they are in Mountain Lion. It's a pleasing changethat few people were asking for but that's obvious in hindsight. Those old icons were abit too small.

System Preferences: now with (slightly) larger icons.

It's otherwise relatively peaceful in the land of preferences, but there are a few buried



gems.

General

The option to turn off text smoothing for font sizes below some threshold has been re-moved from the GUI. It can still be set from the command line, though it's not clear inwhat contexts this setting is even honored these days.

Desktop & Screen Saver

There are a handful of new nature-themed desktop backgrounds, including the attrac-tive wave picture seen in Apple's Mavericks marketing materials and in the back-ground of many screenshots in this review.

Incidentally, that wave desktop picture is 5120 x 2880 pixels, which is exactly doublethe horizontal and vertical resolution of Apple's decidedly non-retina 27-inch Thun-derbolt display. And have you heard that Apple's new Mac Pro can drive three 4K-resolution displays, were you to purchase them from… somewhere? Just wondering.

Language & Region

The former Language & Text preference pane has had most of its text-related optionsmoved to the Keyboard preference pane. Other features are now buried under an"Advanced…" button.



Internet Accounts

The old, incredibly awkwardly named "Mail, Contacts & Calendars" preference panehas been sensibly renamed "Internet Accounts." LinkedIn, a new account type, is inte-grated in a manner similar to Facebook, with link sharing, contacts integration, andOS-level account access with per-application permissions.



LinkedIn is now supported, in case you feel like you don't get enough e-mail already. I kid! I kid because I hate.

Sharing

Though Apple says that SMB2, a newer, more efficient version of the standard Win-dows file-sharing protocol, is "the new default protocol for sharing files in OS X Mav-ericks," traditional AFP file sharing is still both supported and enabled by default—once File Sharing itself is enabled, that is. (Network-based Time Machine backups stillrequire AFP.)

SMB2 has several advantages over Apple's old (but still supported) implementation ofSMB 1.0. SMB2 can combine multiple requests into a single network transaction, re-ducing the number of request/response round trips required to retrieve information.This is especially important given the ever-increasing amount of metadata associatedwith files in OS X. AFP might require several requests just to get all the desired infor-mation about a single file.



SMB2 supports larger reads and writes, making better use of fast networks, especiallythose with high latencies. Support for larger MTU values means that SMB2 has im-proved throughput on very fast networks, like IP over Thunderbolt (which is alsonew in Mavericks).

SMB2 even has an energy-saving angle. Prior to Mavericks, having an open filehandleon an SMB-mounted volume would prevent your Mac from sleeping. SMB2 removesthis restriction. Mavericks will also attempt to transparently reconnect to an SMB2-mounted volume in the case of a network interruption or other server problem.

In case it doesn't go without saying, SMB2 provides better interoperability with mod-ern Windows machines. Mavericks will always use SMB2 when it's available. This istrue even when connecting from one Mac to another. That's right, file sharing betweentwo Macs running Mavericks will use SMB2, not AFP. I wouldn't be surprised to seeAFP deprecated in a few years.

Parental Controls

Parental Controls now include the ability to disable the built-in camera.

Parents, try not to think too much about why this setting exists… but doconsider activating it.

App Store

The new App Store preference pane replaces the Software Update preference panewhose functionality it had already usurped in Mountain Lion.



The default settings will download all newly available updates in the background andwill automatically install updates to the OS itself. There's also a new option to enableautomatic updates for applications purchased through the Mac App store. Maverickswill ask if you want to enable automatic application updates the first time you installa software update, but this feature is not enabled by default. I guess Apple deemed ittoo scary for Mac users, but its day may yet come.

Dictation

The dictation feature introduced in Mountain Lion shared a bit too much with its iOScounterpart, requiring an explicit action, a trip to Apple's servers, and an anxiety-filled pause before the results of the system's labors were shown on the screen. It wasless like dictation and more like sending verbal postcards.

Mavericks includes optional support for offline, continuous dictation. Enabling thefeature triggers a 785MB download.



Enhanced dictation: surely one of the more heavyweight checkboxes in Ap-ple's history.

The offline dictation interface is indistinguishable from its online incarnation, save forthe fact that words appear as you speak.

Recognition is surprisingly good. I'm using Dragon Dictate for OS X to write thesevery words. It costs over a hundred dollars, but it earns its price with extensive cus-tomization features and a recognition engine trained specifically for my voice. Dragonhas no problem transcribing sentences like, "Craig Federighi loves ice cream and OS X10.9."

To its credit, Mavericks gets "ice cream" and "OS X 10.9" right, but it fumbles over"Federighi," a word I've trained Dragon to recognize by feeding it a vast corpus of myown tech writing. Mavericks also doesn't include a menu of alternative interpretationsto choose from when it guesses wrong, nor does it include an obvious way to add tothe system's vocabulary.

Still, it's an impressive showing, especially considering the absence of a requiredtraining process. It even works in a noisy room using the crummy built-in mic on a



MacBook. And hey, you can't beat the price.

Accessibility

Most people probably never visit the Accessibility preference pane. I confess, I'm un-qualified to provide a thorough assessment of the features it provides. But on a longenough timeline, we'll all surely be paying a visit to these settings (or similar ones inwhatever OS we're using in the future). There is no real dividing line between "able"and "disabled"; it's a continuum that we all travel along. You may be surprised to findthat some of these accessibility features are useful to you already.

In that spirit, I encourage everyone to check out the Accessibility preference pane, in-cluding the two new items added in Mavericks: Captions and Switch Control.

Show text captions in videos in one of several styles.



Switch Control provides integration with switch-based input devices. Tryenabling it (under the "General" tab) and check out the "Pointer" feature, us-ing your spacebar as a switch.



Panel Editor is an entire, separate application for creating custom input pan-els.

Apple has always been a leader in accessibility. I'm glad to see that things are still im-proving and expanding in Mavericks.

Integrated graphics improvements

Modern Macs with integrated GPUs get some nice improvements in Mavericks. AnyMac with Intel's HD4000 graphics or better can now run OpenCL on the integratedGPU in addition to the CPU and any discrete GPU. (Core Image now uses OpenCL inMavericks, though the old GLSL implementation remains for backward-compatibilitywith existing Image Units.)

One disadvantage of integrated GPUs is that they borrow RAM from the systemrather than having their own dedicated VRAM. In past versions of OS X, Apple's inte-grated GPU drivers took anywhere from 512MB to 768MB of system RAM and wiredit down, reserving it for use by the integrated GPU only. Mavericks dynamically allo-



cates VRAM for integrated GPUs, using only what it needs and putting RAM backinto the system pool when it's no longer required.

This can result in significant RAM savings. A freshly booted Retina MacBook Pro run-ning Mountain Lion will reserve a full 768MB of system RAM for the integrated GPUeven when just sitting in the Finder. That same Mac running Mavericks will initiallyreserve less than 30MB of VRAM for the GPU, leaving over 738MB of additional RAMavailable for applications. Mavericks also allows graphics-intensive applications to al-locate up to 1GB of VRAM for the integrated GPU.

Apple has been slowly migrating its laptops away from discrete GPUs for years, start-ing with the low-end models and working its way up to the big-money machines. Bythe time you read this, perhaps we'll know if the latest revision of the MacBook Profamily even includes a discrete GPU as an option.

This trend is partly due to the tremendous increase in the performance of Intel's inte-grated graphics solutions in recent years, but it's also heavily driven by energy usage.Integrated GPUs consume far less power than their discrete brethren. The improvedsupport for integrated GPUs in Mavericks is an important part of this transition,bringing the Mac another step closer to the SoC-based world of iOS devices.

Terminal current working directory restoration

The Terminal application in Mavericks will restore the current working directory forwindows running local shell processes. Users of tmux or screen may scoff at suchhalf-hearted, piecemeal state restoration efforts, but those of us who continue to resistthe lure of terminal virtualization really do appreciate the change.

Even (or perhaps especially) if you can't make heads or tails of the preceding para-graph, you might still enjoy this feature. To try it for yourself, launch the Terminal ap-plication, type cd ~/Documents at the shell prompt in the window that appears,quit Terminal, then relaunch it. When Terminal launches again, your window shouldbe restored to its previous state, including the current working directory (your Docu-ments folder). To confirm this, type pwd at the shell prompt. You should see a pathlike /Users/<username>/Documents.

Special characters popover

The "Special Characters…" item in the standard Edit menu now has a default key-



board shortcut: command-control-space. Triggering it (via the keyboard shortcut orotherwise) reveals a new popover that's placed at the current text insertion point.

Special characters, now in popover form, available through a new keyboardshortcut: command-control-space.

This popover can be torn off into a floating palette, which can then be expanded intothe full character selection window as seen in Mountain Lion and earlier.

Special characters palettes. Click the icon in the upper right to switch to thefull character palette.

System font

Mavericks uses a slightly different variant of Lucida Grande as its system font. It'ssupposedly "optimized for Retina displays," whatever that means in the context of anoutline font, but I'll be damned if I can spot the differences without the help of an im-age editor. Try your luck.



System fonts: Mountain Lion on the left, Mavericks on the right. I swear toyou these images are not identical.

Recommendations

At the end of my Mountain Lion review, I wondered if an annual release schedule forOS X allowed enough time for any major release to mature into a stable, reliable plat-form. I needn't have worried; it didn't take long for Mountain Lion to settle down.

After three releases in three years, Apple has proven the viability of yearly releases. Itcan be done—but should it be? Despite their shared technical underpinnings, upgrad-ing to a new major release of OS X is still fraught with considerably more peril thanthe one-tap iOS update experience. (Remember when Apple used to call them "iPhoneFirmware" upgrades?)

We're all conditioned to expect iOS devices to behave in an appliance-like manner.But when it comes to the Mac, both Apple and its customers are victims of their ownexpectations. Users assume that major personal computer OS updates are complexand dangerous (they certainly have been in the past), so they're hesitant to upgrade.

Apple, meanwhile, is extremely cognizant of its customers' preconceived notionsabout what makes a Mac different from an iOS device: free access to the file system,the ability to download and install applications from anywhere on the Internet, richinter-application communication, extensive customization. But many of these thingsare exactly why the OS X upgrade experience has yet to reach iOS levels of reliabilityand simplicity.

This tension continues to play out in Mavericks, with Apple tugging the Mac evercloser to the iOS ideal while its customers continue to eye any OS X release with anew second version number warily.

Then there's the question of scope. It's nice to get new features and refinements everyyear, and stability doesn't seem to be a problem. But what about things that take morethan a year to create? Case in point: we've been waiting for a new file system for yearsnow. That type of project doesn't fit within a 12-month release cycle, and it will onlybe delayed further if it has to constantly chase after and synchronize with yearly re-leases.

And let's not forget the financial realities of Apple's iOS product lines, which dictate



engineering resource allocations that decidedly do not favor the Mac platform. Per-haps Apple doth protest too much with its annual OS X releases and frequent declara-tions of (re)dedication to the Mac platform. It's enough already, Apple. We get it. Weall saw the new Mac Pro. If you go away for two years to work on an earth-shatteringnew release of OS X, we won't flip out and declare the Mac dead.

All of this is a roundabout way of getting to the essential question of any OS review:should you upgrade? OS X is (still) not iOS. The upgrade risks are greater, and thereis no easy iCloud-based backup and restore for your Mac to save you if things goawry. If you're currently running Mountain Lion, is there anything in Mavericks thatmakes it a must-have upgrade?

If you're using a Mac laptop, I'd say yes. A potentially multi-hour increase in batterylife will likely improve the quality of your life as a Mac user far beyond the price—interms of time, not money this year—of upgrading to Mavericks.

If you have a desktop Mac, I still recommend upgrading if any of the features thatyou've read about made you mentally exclaim, "Finally!" For me, there are several.Over the past three years, each successive release of OS X has found its way onto all ofmy Macs in less time than its predecessor. This year, I may have already gone Maver-icks-only across my whole household by the time you read this. Barring any unfore-seen bugs or compatibility issues, Mavericks seems like a no-brainer upgrade to me.But you can be sure I'll have a fresh set of backups—and you should too.

Changeover

Absent knowledge of the recent upheaval in Apple's leadership, Mavericks mightlook like a minor aesthetic course correction. Just as Mac OS X 10.0, codenamed Chee-tah, was actually the slowest version of OS X, Mavericks is the least-rebellious releaseof OS X in years. It certainly does little to distinguish itself visually. At a glance, evenseasoned Mac users will be hard-pressed to tell a Mac running Mavericks from onerunning Mountain Lion.

And yet, beneath the surface, large, polished steel gears continue to turn on Apple'soldest shipping software platform. I'm not sure if we'll ever see a radical rethinking ofthe OS X interface in the vein of iOS 7, but that's not the only way a sea change canmanifest. As Steve Jobs famously reiterated, design is not just what a product lookslike and feels like. Design is how it works.



In his day, Steve Jobs had plenty to say about how the Mac should work. Upon seeinghow quickly Apple's iOS devices were ready for use after waking from sleep, rumorhas it that Jobs asked his hardware team why the Mac, with its orders of magnitudemore computing power and resources, couldn't also be like that.

In the years that have passed since then, the Mac has indeed been on a steady marchtoward the functional ideal embodied by the iPad, a product that is arguably the cul-mination of Jobs' original vision of personal computing. Though the surface of OS Xcontinues to roil and fluctuate, the underlying transformative process that began inLion continues apace in Mavericks. In previous years, iOS-like simplicity was the tar-get. This time, it's the iPad's battery life and responsiveness that the Mac is chasing af-ter.

As Apple will readily tell you—at length—this is the kind of task a company that de-signs both the hardware and software is uniquely well-suited to execute. But as thepast three releases of OS X have shown, it's a lot easier to create something like theiPad starting from a clean slate than it is to take an existing, decades-old product line,with all its attendant customer expectations, and gently herd it toward a new destina-tion.

As for the aforementioned roiling surface, it can't be ignored entirely. Whatever thefaults may be of the awkwardly disrobed Mavericks incarnations of the formerlyleather-bound and book-like applications from Lion and Mountain Lion, there's nosense in looking backward. We're just not sure what comes next—and neither is Ap-ple, it seems.

An internal, functional metamorphosis combined with an uncertain aesthetic direc-tion, with a dash of anxiety about relevance mixed in—all of this has produced an OSthat even a new Mac user might peg as a bit unsure of itself. Sometimes, gentle herd-ing isn't enough; things have to be torn down before they can be rebuilt. An anthropo-morphized OS X Mavericks would likely be a bit of a mess—a nervous Woody Allennext to iOS 7's confident Brad Pitt—but it could at least offer that new Mac user a rea-sonable explanation: You met me at a very strange time in my life.

Mac OS X Mavericks - John Siracusa's Ars Technica review

Technology

Transcript of Mac OS X Mavericks - John Siracusa's Ars Technica review