When the book is finally closed on the product line known as OS X, last year’s release ofOS X 10.9 Mavericks may end up getting short shrift. Sure, it broughttangibleenergy saving benefits to Mac laptop owners, but such gains are quickly taken for granted;internalchanges andnew frameworks are not as memorable to customers as they may be to developers and technophiles. And while Mavericks includedmanynewuser-visible features, and evennewbundled applications, the cumulative effect was that of a pleasant upgrade, not a blockbuster.

Ars Technicapremier subscribers can download a (free) Kindle or iBooks-compatible EPUB version of the complete review from the links in the “tools” menu on the upper right of each article page.

Non-subscribers canbuy the e-book from the iBookstore or theAmazon Kindle store.

But for all itstimidity and awkwardness, Mavericks marked a turning point for OS X—and in more than justnaming scheme. It was the first OS X release from the newly unified,post-Forstall Apple. IfiOS 7 was the explosive release ofJony Ive’s pent-up software design ethos, then Mavericks was the embodiment ofCraig Federighi’s patient engineering discipline. Or maybe Mavericks was just a victim of time constraints and priorities. Either way, in last year’s OS X release, Appletore down the old. This year, finally, Apple is ready with the new.

To signal the Mac’s newfound confidence, Apple has traded 10.9’sobscure surfing location for one of the best known and most beautiful national parks:Yosemite. The new OS’s headline feature is one that’s sure to make for a noteworthy chapter in the annals of OS X: an all-new user interface appearance. Of course, this change comes a year after iOS got itsextreme makeover.

Ah, the old tension: which platform does Apple love more? iOS continues to dominate Apple’s business in terms of unit sales, revenue, and profits. Last year, some Apple watchers had openly wondered whether Apple would even bother updating the look of OS X. And yet for the past several years, Apple has loudly and publicly insisted that itremains committed to the Mac as a strong, independent platform. Yosemite aims to fulfill that commitment—but in an interesting way.

All together now

OS X and iOS have been trading technologies for some time now. For example,AVFoundation, Apple’s modern framework for manipulating audiovisual media, was released for iOS a year before it appeared on OS X. Going in the other direction,Core Animation, though an integral part of the entire iPhone interface, was released first on the Mac. Yosemite’s new look continues the pattern; iOS got its visual refresh last year, and now it’s OS X’s turn.

But at this year’sWorldwide Developers Conference, Apple made several announcements that point in a new direction: iOS and OS X advancing in lockstep, with new technologies that not only appear on both platforms simultaneously but also aim to weave them together.

These new, shared triumphs run the gamut from traditionalframeworks andAPIs tocloud services to the very foundation of Apple’s software ecosystem, theprogramming language itself. Apple’sdramatic leadership restructuring in 2012 putFederighi in charge of both iOS and OS X—a unification of thought that has now, two years later, resulted in a clear unification of action. Even the most ardent Mac fan will admit thatiOS 7 was a bigger update thanMavericks. This time around, it’s finally a fair fight.

Installation

Software distribution has undergone a long, slow transformation that’s been driven, like so many other things, by the popularization of the Internet. Charts detailing theschedule andpricing of OS X updates have been a staple of past reviews, but with Mavericks, OS X apparentlyreached its final form: free, download-only, updated annually.

Yosemite maintains the status quo, right down to the list of supported Mac models, which remains the same for the third year running. Any Mac that can run Mountain Lion or Mavericks can also run Yosemite. (See our Mavericks review for acomplete list.)

The formula appears to work. While only 35 percent of Mac users had upgraded toMountain Lion in the first six months after its release, the majority of Mac users were running Mavericks after a similar time period. Apple touted OS X’s improved adoption in its most recentWWDC keynote, calling it “the fastest adoption ever of any PC operating system,” and contrasting it with the sluggish uptake of the two-year-old Windows 8.

(A similar chart shown later in the same presentation emphasized how far OS X still has to go, however; eight months after the release of iOS 7, a full89 percent of the installed base was running it. Yikes. We’ll get ’em next year, I guess—anda slow start for iOS 8 may make that easier.)

The actual installation process is drama free and should be familiar to anyone who has upgraded OS X in the past few years. Just hit the Mac App Store, click a few buttons, and prepare to endure a couple of restarts and a lot of staring at progress bars.

There is one surprise in store for those who keep a close eye on their disks, however. Let’s start with the simplest possible installation target, a MacBook Pro’s internal hard drive with a single HFS+ volume.

% diskutil list…/dev/disk2   #:                    TYPE NAME            SIZE       IDENTIFIER   0:   GUID_partition_scheme                *1.0 TB     disk2   1:                     EFI EFI             209.7 MB   disk2s1   2:               Apple_HFS Quicksilver     999.9 GB   disk2s2

After installing Yosemite, our simple HFS+ volume has now become the loneLogical Volume in a newly createdCore Storage Logical Volume Group.

% diskutil cs listCoreStorage logical volume groups (1 found)|+-- Logical Volume Group B9CD7D11-BC78-4F74-9FCF-139406CB6E0E    =========================================================    Name:         Quicksilver    Status:       Online    Size:         999345127424 B (999.3 GB)    Free Space:   5497978880 B (5.5 GB)    |    +-< Physical Volume 1F0C1FE3-E539-4B5D-BF7C-B2608215DC14    |   ----------------------------------------------------    |   Index:    0    |   Disk:     disk2s2    |   Status:   Online    |   Size:     999345127424 B (999.3 GB)    |    +-> Logical Volume Family 8579FE70-5A40-4DA5-8858-97094D        ----------------------------------------------------        Encryption Status:       Unlocked        Encryption Type:         None        Conversion Status:       NoConversion        Conversion Direction:    -none-        Has Encrypted Extents:   No        Fully Secure:            No        Passphrase Required:     No        |        +-> Logical Volume 0760311D-CF5A-497F-9D5B-35F8A69A63EE            ---------------------------------------------------            Disk:                  disk3            Status:                Online            Size (Total):          993494827008 B (993.5 GB)            Conversion Progress:   -none-            Revertible:            Yes (no decryption required)            LV Name:               Quicksilver            Volume Name:           Quicksilver            Content Hint:          Apple_HFS

Core Storage was introduced inOS X 10.7 Lion, ostensibly to support the new, vastly improvedFileVault, Apple’s whole-disk encryption system. Given thelamentable state of file system technology at Apple, Core Storage wasa beacon of hope in 2011. OS X 10.8 Mountain Lion came and went in 2012without any advancement on the file system front, but Apple had a surprise in store for us before the year was out:Fusion Drive, also powered by Core Storage.

Here we are in 2014, and HFS+ is still going strong. Yet here’s Core Storage once again, this time without any obvious purpose. Examination of the listing above reveals that installing Yosemite does not automatically enable FileVault encryption, and Fusion Drive isn’t involved at all in a single-volume installation scenario.

FileVault, Fusion Drive, and thediskutil man page provide ample evidence of Core Storage’s capabilities and purpose, but technical information has been hard to come by. As far as I’m aware, there is no direct, public API for Core Storage, so a lack of external technical documentation is not surprising. The limited implementation details about Core Storage provided by Apple make clear that it does include features found in many modern file systems: redundant storage of metadata (“ditto blocks” in ZFS parlance) and copy-on-write B-trees (shades ofBtrfs)—diminished though they may be by the eventual layering of HFS+ on top of Core Storage.

Given that Core Storage is a prerequisite for both FileVault and Fusion Drive, and given that FileVault encryption is now offered as an option during system setup, the boring explanation for this move is that it just makes sense to apply Core Storage by default—if only to avoid a second reboot needed to convert the volume to Core Storage if the user chooses to enable FileVault during the OS installation process.

But I don’t like the boring explanation. In the absence of any contradictory truths, I choose to believe that this default application of Core Storage is at least partially intended to lay the groundwork for a future in-place conversion of HFS+ volumes toa new, superior file system from Apple. (And if you think I’m Charlie Brown to Apple’sfootball-holding Lucy on this topic, remember that persistence issometimes rewarded…)

[Update: Here’s one contradictory truth. Core Storage is not applied toall installation targets. For example, installing onto an external hard drive will not convert the volume to Core Storage.]

During the Yosemite setup and account creation process, iCloud continues its steady march toward the domination of all authentication functions on Apple platforms. Users who choose to enter an Apple ID when prompted will now be given a further option, enabled by default, to link their local account and Apple ID passwords. (This is a step up from the previous option, which merely allowed a local account password to be reset using a specific Apple ID password.) Once an account is linked to an Apple ID, attempting to change the password offers an option either to change the Apple ID password or to divorce the account from the Apple ID by giving it a separate password.

Having fewer passwords to remember is certainly a good thing, but if you are at all concerned about the power already inherent in access to an Apple ID—including the potential ability toremotely wipe iOS devices and Macs—making your Apple ID password vulnerable toshoulder surfing every time you unlock your MacBook in a café or airport may not be a wise choice.

Branding

In past OS X reviews, Apple’smarketingmaterials have beenmined for hints about the company’s intentions. In the absence of any dramatic visual changes to the software itself, ancillary content like retail product packaging (back when OS X was a physical product), Apple’s OS X website, and even the default desktop background must fill in the gaps to make each new OS X release into a coherent, distinct product in the minds of customers who have not yet installed it.

Yosemite’s branding initially seems a bit on-the-nose, leaning heavily onEl Capitan andHalf Dome, two of Yosemite National Park’s most iconic features. But the other repeated element, the wispy cloud partially obscuring the rock face, is actually a strong hint of things to come.

As we’ll see in a moment, Yosemite is less in need of external visual augmentation than any release of OS X since10.0. Thanks to Yosemite’s comprehensively resurfaced UI, every screenshot is part of the branding.

Yosemite’s new look

In the months leading up to the release ofiOS 7, conventional wisdom held that the era ofskeuomorphism in Apple’s user interface design was drawing to a close. In its place, Apple watchers expected a “flatter” style similar toMicrosoft’s Metro UI, introduced inWindows Phone 7 and later extended toWindows 8.

Despite what seemed like widespread agreement thatstitched leather and tiny strips of torn paper were a bridge too far, the anti-skeuomorphism backlash was already forming a backlash of its own. One month before Applerevealed iOS 7 at WWDC 2013,Panic designerNeven Mrgan cheekilyexplored the continuum:

Are you undecided in the great Flat vs. Skeuououmourphic design debate of 2012? Are you unsure of how flat is flat enough (but nottoo flat)? Wondering what it means tolet a button be a button? Use this handy chart to pick the button that looks like a button to you!

Reflecting on his post in light of the eventual reality of iOS 7, Mrganmused that the “joke” options in his image turned out to be exactly what we got: buttons consisting of text labels and nothing else.

Apple has tried toexplain to developers the contexts in which label-only “buttons” work best, and it has conceded that in some situations, drawing borders around buttons is still the best choice. IniOS 7.1, Apple went further, adding a system-wide option to enable “button shapes.”

I’ve rehashed this recent iOS history to set the stage for Yosemite. As with iOS 7, a redesign was expected in OS X 10.10. But this time, we knew exactly how far Apple was willing to go. Visions of a radical new OS X danced in our heads: impossibly thin Helvetica text, no shadows below windows, application icons all forcibly contained in rounded rectangles, every toolbar icon reduced to monochromatic wireframes, every button transformed into a simple text label, and white—everywhere, white!

Let’s start with the most basic interface element, the title bar. Here’s where we were in Mavericks:

And here’s Yosemite:

So far, so good, right? The traffic-light widgets are flattened, as expected, transforming from glossy gumdrops toflat circles. The title bar itself is lighter, but it’s hardly stark white. The system font (as seen in the window title) has changed from Lucida Grande to Helvetica Neue.

I expect the font change to be well below the radar of the vast majority of Mac users, but it is (perhaps surprisingly) relevant to developers. Though Apple has gone to some lengths to keep the metrics similar for both fonts, text rendered in Helvetica Neue may be either longer or shorter than the same text rendered in Lucida Grande, depending on the exact sequence of characters. When applications that were built against the Mavericks SDK or earlier are running on Yosemite, the system will compress the spacing in any text that uses the system font if it becomes too large for its container. This may be ugly in places, but squished beats truncated any day.

Moving on from the title bar, Yosemite’s standard controls are similarly reassuring. Here’s a sampler:

Compared tothe Mavericks equivalent, Yosemite knocks down a lot of the depth, surface detail, and shadow lines while also cranking up the saturation in the blue highlight color. Without the gleam and polish of its predecessors, Yosemite’s new look relies on crisp edges and fine lines.

While Mavericks on aRetina display sometimes dipped into theuncanny valley, looking almost—but not quite—photorealistic, Yosemite’s design plays to Retina’s strengths. On non-Retina displays, Yosemite seems uncomfortable, descending into soft-edged blandness. If Retina desktop Macs still haven’t been announced by the time you read this, Apple had better hurry up.

Control metrics have not changed much, but some of the new visuals are striking. Progress bars are considerably simplified, transforming from shiny, puffy, pulsating barber poles to mere strips of blue, with a subtle gradient detail in the indeterminate progress bar only. Also note the centering of the placeholder text in the search field.

But most importantly, buttons and other controls still have recognizable shapes and are clearly distinguished from the background. Several controls even have gradients to indicate some surface curvature. If this is flat design, it’s flat design with an asterisk, at the very least. It seems like we were all worried for nothing. But don’t get too comfortable…

Vibrancy

Yosemite has one more trick up its sleeve, and it’s a doozy. Take a look at this Finder window:

While title bars and standard controls may look reassuringly familiar in Yosemite, toolbars and sidebars (source lists, in Apple’s parlance) subvert their plain gray coloring by allowing other content to leak through. Apple calls this new effect “vibrancy.” In addition to the expected transparency and blur filters, vibrancy also intensifies and pulls forward the color information from the background.

In the screenshot above, note the colors bleeding through the title bar from the image thumbnails that are scrolling up “behind” it. This is the “within window” blending mode, where content inside the window itself (usually in a scrolling view) shows through other interface elements in the same window. In the sidebar, the orange sky and outline of the mountain from the desktop background are faintly visible. This is the “behind window” blending mode; it shows whatever is directly behind the window, whether that’s the desktop or another window—but it always mixes in a hint of the desktop picture.

Yosemite has dark and light vibrancy appearances, plus a special material specifically for window title bars. The effect is subtle and should be familiar to anyone who has used iOS 7.

Vibrancy is used throughout the OS, including in nearly every transient or otherwise “layered” interface element: pull-down and context menus, sheets, the menu bar, Notification Center and associated alerts, and even the Dock. The filter settings appear slightly different in each of these contexts, but the family resemblance is clear.

Vibrancy is not limited to standard controls or to the OS itself. Third-party developers can apply it to any view within an application, choosing both the blending mode and the appearance. Furthermore, source lists used in third-party applications will automatically get the new translucent look, as will any toolbar with an adjacent scrolling view.

It’s surprising to see such dramatic appearance changes applied by default to third-party applications (though this is somewhat moderated by the specific technical details of what constitutes a “source list” and an “adjacent scrolling view”), but it does show how committed Apple is to this look. Expect to see it everywhere in the OS, in all major bundled applications, and in at least a few third-party applications.

These visual effects aren’t free; they cost CPU and GPU cycles each time the foreground or background changes. Behind-window blending is implemented in the window server, which is responsible for compositing all the visible windows into the final screen image. (This compositing process has beenGPU-accelerated since 2002.) Moving a window that uses vibrancy in the behind-window blending mode does not require the application that owns the window to redraw any content; the window server handles the re-compositing as the background changes.

Within-window blending, on the other hand, is handled by each individual application. The system frameworks useCore Animation layers (also GPU-accelerated) to apply the necessary filters, blending, say, the contents of a scrolling view with the toolbar that partially covers it.

Given Apple’srecent focus on energy saving in Mavericks, it’s a bit strange to see Yosemite lean so heavily on a dynamic effect like vibrancy. To keep things from getting out of hand, vibrant views become opaque when inactive. In practice, this means only the front-most window in the currently active application—plus the Dock, menu bar, and any notification alerts that may dance across your screen—will burn cycles artistically blending foreground and background content.

Animation

Many standard controls now have state-change animations in Yosemite. The various fades and zooms are fast and subtle, for the most part, though the shrink-to-fit focus ring animation might be a bit over the top.

Is this really the same Apple that, just last year,disabled the Time Machine menu bar icon’s animation, presumably for energy-saving purposes? To be fair, there is a significant difference between brief animations triggered by user input and continuous animations that run whether the user is present or not. Though Yosemite may indulge in the former, Apple’s crusade against the latter continues.

Consider the default button in a dialog box. Since the very first version of OS X, default buttons have changed their appearance many times but have always retained a subtle pulsing animation. That animation is gone in Yosemite; default buttons are just as static as non-default buttons. (The Time Machine menu bar icon animation has not returned, either.)

Icons

Fears of an iOS-styleround rect icon revolution on the Mac may have been unfounded, but Appleis trying to discipline the world of OS X icons. While one icon shape has been deemed insufficient, Apple believes three shapes should just about do it: circle, rectangle, and tilted rectangle.

The circle and rectangle shapes are long-standing traditions on OS X. The tilted rectangle is slightly different than the icon style it replaces in that the projection is noworthographic; areas further from the “camera” are no longer smaller, as they would be in aperspective projection.

Most of Apple’s tilted rectangle icons still represent tangible things: pads of paper, tiny books, photographs, gadgets. It’s the surface details that really differentiate Yosemite’s icons. Visual simplification is the order of the day, and details that don’t read well at small icon sizes have been excised. The new style makes the icons look slightly more, well, iconic. There’s also a bit ofmood lighting at work here, as if each icon exists in an eternal “magic hour” just before sunset.

Some application icons have not been updated at all, but among those that have been refreshed, I see only a few misses. Terminal has been robbed of all character and flair, now appearing as an almost featureless black rectangle whose connection to Apple’s latest display hardware takes a sharp eye (and maybe a Retina display) to discern. Thechunky QuickTime Player icon introduced five years ago has been revised—for the better, I think—but it’s still not much of a looker. If I really want to pick nits (and I do), the FaceTime icon’s telephone badge obscures the camera shape, producing a green jumble. (Both shapes are also anachronisms.)

Finally, consider that most quintessential of icons, the humble folder. No longer open a crack like its predecessor (or if it is open, then orthographic projection hides the fact), the Yosemite folder is, perhaps, less inviting. But the shape is less noticeable than the color: a swimming-pool-caliber blue-green.

Of all the visual elements in Yosemite, this is the one that doesn’t seem to fit in with the rest. Instead of being bathed in the light of a sunset, these folders look like color chips from a ’70s bathroom tile catalog. And there’s not much harmony between folders and the highlight colors used on controls like default buttons and pop-up menus. Still, I’m willing to believe a little friction can add interest to a design.

Time Machine

Time Machinedebuted as one of the most flamboyant features Apple has ever added to OS X, both in terms of ambition (make backup easy enough that anyone can do it) and user interface (make backups fun, so people willwant to do it).

But just as the days ofstitched leather have come and gone on the Mac, so too has the era of thenon-functional swirling space vortex background. In its place, Yosemite offers standard-looking buttons and a now-familiar blurred background.

The Dock

The “3D” Dockintroduced in Leopard has remained a sore spot to those with a special sensitivity to visual incongruity. The surface details have changed in the years since, but Apple hascontinued to render the Dock as a virtual shelf upon which application icons (uncomfortably) sit.

While its horizontal cousin was tripping the light fantastic withreal-time reflections andmachined edges, the vertical Dock stuck to a simple, two-dimensional look. In Yosemite, the two Dock appearances have finally become one. Vanishing points and surface textures are out;vibrancy is in.

The Yosemite Dock aggressively pulls background colors forward, more so than even the relatively transparent pull-down and context menus. A different background image can have a dramatic effect on the appearance of the Dock. (Also note the trash can’s new, smoky look that matches well with the rest of the system.)

Apple’s ongoing war against whimsy continues with the retirement of the adorable puff-of-smoke cursor and subsequent animation when removing an item from the Dock. In its place, Yosemite shows the word “Remove” while dragging, and it simply makes the icon disappear upon release. Along the same lines, theglowing indicator lights shown under running applications have been replaced by straightforward (tiny) dots. Progress bars on Dock items are thin stripes of black ink.

It’s worth noting that this is the first time in many years the Dock has used the same appearance in both its vertical and horizontal positions. Setting aside the particulars, the Yosemite Dock exudes a visual confidence that has been sorely missed in the past few releases of OS X.

Philosophy

For the most part, a new look for an operating system doesn’t need to justify itself. It’s fashion. We all want something new every once in a while. It just needs to look good. But things start to get complicated when fashion butts heads with usability—then we want reasons.

Though I’ve tiptoed around it thus far, the friction point in Yosemite’s new visual design is its pervasive use of transparency. (Technically, “translucency” is more accurate, but please indulge my idiomatic usage.) Allowing what’s behind to influence the appearance of what’s in front is problematic in a couple of ways. From a purely aesthetic perspective, transparency is unpredictable. Designers can decide which aspects of the background will influence the foreground image, but they can’t control the content of that background. Will its contribution make the final image more pleasing, or will things turn ugly?

In terms of usability, transparency risks impairing readability and recognition. Colors bleeding through from other content can undermine the intended contrast between text and its background. Symbols and shading meant to subdivide an interface can be sabotaged by the influence of unrelated background images. The content as designed by the application developer is the signal; any background content that shows through is noise.

This is not Apple’s first transparency rodeo, however. Early versions of OS X faded some interface elements almost to the point of invisibility. The look made for a nice demo (14 years ago, anyway), but readability wasseverely compromised in some cases. The problem was exacerbated by the lack of additional image processing (e.g., blur) applied to the background. (At this point in OS X’s history, all compositing was done on the CPU.)

Later versions of OS X toned down the transparency and eventually incorporated additional effects to make background content even less distracting. InLeopard, Apple once again succumbed to the siren call of transparency, deciding the world really needed to see more ofwhat’s behind the menu bar. In another repeat of history, pre-release builds of Leopard includedeven more extreme transparency, which was moderated before release. (Menu bar transparency was eventuallymade optional in 10.5.2.)

Apple has taken great pains in Yosemite to ensure that any content that does show through transparent interface elements is extremely diffuse and indistinct. But the aspects of the background that do show through—mostly color—are often magnified.

Inevitably, I find myself searching for a reason. Why is it important for me to seeany aspect of what’s behind the front-most active window? Why risk reducing both the usability and attractiveness of the UI? To what end?

Apple has offered many different justifications for this aspect of Yosemite’s new look. In the WWDC keynote, Craig Federighi explained in-window blending in the Finder—icons scrolling “behind” the toolbar—by saying, “The use of translucent materials gives you a sense of place as you scroll your content.” Given thedisappearing scroll bars introduced in Lion, a vague, colored haze showing through the toolbar may indeed be the only indication that more content is available above the currently visible region, but I’m not sure how strong that signal will be to most people.

Federighi also described translucency as a tool for visual customization. “Now your windows take on the personality of your desktop. As you change your desktop picture, your window adapts to reflect that personality and that temperature.” This works best if there’s nothing between a window and the desktop background. The strongest influence on the “personality and temperature” of a window on a busy OS X system is the content of some other window, which is more difficult to control than the desktop picture.

(The most obvious demonstration of this aspect of vibrancy is the menu bar. It pulls color from the desktop picture behind it, but this color also appears in each pull-down menu. Even if a completely white window is behind a pull-down menu (or any other vibrant surface), it will be tinged with the color of the desktop background.)

Ina later WWDC session, Mike Stern, a User Experience Evangelist at Apple, espoused the idea that software interfaces should have plausible physical dimensionality and that this dimensionality helps the user “to focus on the things that are in the foreground and pay less attention to those things which are in the background.” Stern noted aspects of OS X’s design (like gradients and drop shadows) that contribute to dimensionality, but he also cited the use of transparency in elements like Notification Center.

I don’t think Notification Center, menus, and the Dock need to be transparent for me to understand that they’re on top of the other things on the screen. Even setting aside the drop shadows, the fact that these interface elements are drawn on top of everything else gets the point across just fine.

There’s a kernel of truth in Apple’s justifications for the widespread use of transparency in Yosemite. Surprisingly, the one I find myself agreeing with the most is transparency as a vector for personalization—or, at the very least, variety. As notedearlier, the Yosemite interface really does look quite different depending on what’s behind the various translucent interface elements. I’m not sure how much control users will have over this aspect of the experience, but at the very least, the desktop picture can spread its tint to all vibrant surfaces while also strongly influencing the menu bar and the Dock (assuming people don’t slide windows behind it).

As much as I may support any of these lines of reasoning, my tolerance for any instance of impaired readability due to background “leakage” is very low. Others feel differently, I’m sure, but I find myself wishing that Apple had chosen an attractive, signature look for “non-transient” elements like windows and sidebars that was based on completely opaque artwork. Interestingly enough…

Escape hatch

One rationale Apple hasn’t emphasized much is that transparency makes the interface more attractive. One might assume this is implied; Apple’s not the kind of company known for adding visual effects to aid usability at theexpense of aesthetics.

Of course, that’s exactly what Apple has always done with its accessibility features. Massive magnification or an inverted color palette do not make forattractive screenshots, but these features make OS X more usable for people with certain kinds of visual impairments.

Yosemite includes a new “reduce transparency” option in its Accessibility preference pane, aimed at addressing possible usability problems created by the OS’s new look. Enabling this option removes transparency nearly everywhere. The Dock, menu bar, toolbars, sidebars, context menus, sheets, Notification Center—all completely opaque.

Opaque Yosemite doesn’t look bad at all. It’s a little boring, perhaps, especially the Dock, but I can imagine almost anyone using it and being satisfied. This is a testament to the design of Yosemite’s new look; it may (or may not) benefit from transparency, but it doesn’t rely on it to look good and work well.

There’s also an “increase contrast” option that activates reduced transparency, increases the contrast between text and its background, and draws darker, thicker outlines around most standard controls. It looks a lot like someone has taken to your screen with a fine-point marker.

Visually speaking, this is all a lot to take in—and we’ve barely scratched the surface of Yosemite’s interface changes beyond its new coat of paint. We’ll get to that in the next section, but before we leave the world of colors and finishes, there’s one more twist to consider.

Variations on a theme

In the early days of OS X, I remember reflexively checking the General preference pane in each new pre-release build of the OS to see if the “Appearance” pop-up contained more than just the “Blue” and “Graphite” options. Back then, the Mac was coming off an era of unprecedented appearance customization capabilities. Steve Jobs returned to Apple just in time to nix the release of Apple’s own alternate appearance themes, but he was too late to stop the release of the framework that made classic Mac OS themes possible: the mightyAppearance Manager.

Third-party system extensions likeKaleidoscope rushed in where Apple feared to tread. I had hundreds of Kaleidoscope “schemes” (as they were called), plus Apple’s own, unreleasedHi-Tech,Gizmo, andDrawing Board themes. Truly, it wasa golden age.

All these years later, OS X still offers the same two appearance options: Blue and Graphite. In Yosemite, the Graphite option is finally much closer to a completely neutral gray than the blue-tinged gray that preceded it. This should be a boon to people who work with color and don’t want to be unduly influenced by the interface chrome. (For me, Graphite will always be “the boring option.”)

Yosemite does have one surprise up its sleeve, however. The General preference pane contains a new option to switch the menu bar and Dock to dark backgrounds with light text. The command-tab switcher and Spotlight interface also adopt the darker theme, but window chrome and standard controls remain unchanged.

The return of the Appearance Manager it’s not, but the look does have a certain sinister appeal. Reinforcing the reality that the days of theme-savvy interface APIs on the Mac are long gone, dark-mode aficionados can expect to see some third-party menu bar icons that blindly draw themselves and/or their menu contents in black, leading to an unreadable black-on-black appearance. (The recommended usage of the relevantNSStatusItem class has been heavily revised in Yosemite; developers havesome work to do.)

The potential for similar bugs in the interface of applications themselves might explain why the dark theme doesn’t extend to more of the interface. As it stands, the theme is so limited that some people may wonder why it’s included at all. Apple says this feature was motivated by a desire to tone down the brightness of these always-visible interface elements and to better match the dark UI of pro applications like Aperture. Whatever the reasons, after all these years of just Blue and Graphite, I’m excited to see Apple dipping its toe back into the world of appearance customization.

Interface changes

Design, as theysay, is not just how somethinglooks and feels. Design is how it works. The entire interface doesn’t just look different in Yosemite; major pieces work differently as well.

Spotlight

Following in the footsteps of venerable quick-access launchers likeLaunchBar andQuicksilver as well as (relative) youngsters likeAlfred, the Spotlight search field now appears front and center when activated. This may seem like a trivial change, but it transforms the user experience. What wasonce an awkward, non-standard text field sprouting from a tiny icon in the corner of the screen is now a wide, inviting window with very large text.

A preview area has been added to the results window, providing aquick look at the highlighted result. Spotlight’s purview has expanded to encompass locations (via Apple’sMaps), digital media (iTunes), software (the App Store), and results from well-known websites like Wikipedia, all with nice inline previews.

The up and down arrow keys can be used to select (and preview) each result. Holding down the command key when a file or folder result is selected will display the path to the item.

In addition to the simple mathematical calculations it already handles, Spotlight in Yosemite now does unit conversions faster than you can type the same query into a Google search box.

As always, all these data sources can be toggled using the Spotlight preference pane (though it’s sometimes difficult to tell which source is responsible for a result).

They may all seem like minor changes, but the cumulative effect is significant. The interface looks and behaves differently enough that I suspect some people may view it as an entirely new feature rather than a simple evolution of Spotlight.

The aforementioned third-party launchers will likely always have more features and customizability, but Spotlight in Yosemite is the first version that actually has a shot at keeping me from immediately installing my ownpreferred launcher on any new system. (The one basic feature I miss is the permanent retention of the previous search between activations. This makes re-launching the previously launched application—a common occurrence in post-auto-termination OS X—as simple as typing command-space and then hitting return.) For anyone who has never even heard of this entire category of launcher applications, the new Spotlight is a big step in the right direction.

Notification Center

Notification Center changes its appearance, animation, and purpose in Yosemite. It still slides out from the right edge of the screen, but it’s now a sheet of darkvibrancy that overlaps the screen rather than pushing the entire screen image to the left. A tab bar at the top switches between the interface’s two functions: displaying notifications and showing an iOS-style “Today” view. Everything that’s not a notification (e.g., the widget used to send an instant message or write a tweet) has moved into the Today view.

The contents of the Today view are almost entirely customizable. The day and date cannot be removed from the top (which is a shame), but every other item can be reordered or removed (though the Today and Tomorrow widgets seem stuck at the top and bottom, respectively). Individual widgets can be configured by clicking an easy-to-miss “i”-in-a-circle icon that appears in the upper-right corner of each widget on mouse-over. Most importantly, installed applications can add new Notification Center widgets (through a mechanism that will be explainedlater).

If this sounds a lot likeDashboard, it’s no coincidence. Though Dashboard still exists in Yosemite (now with aLaunchpad-like blurred background), it hasn’t had any noteworthy updates in years. I would not be surprised to see Dashboard disappear in the next major release of OS X. After 10 years, it’s had a good run, but Apple is clearly ready to move on.

Full screen

It’s not often that the window title bar changes on the Mac, so when the full screen widgetappeared in Lion, occupying the former home of the short-lived and fabulously purplesingle-window mode toggle, it demonstrated Apple’s commitment to this new feature.

In Yosemite, full-screen mode graduates to the next level, evicting the former functionality of the green stoplight widget. The far right corner of the standard OS X window title bar is now, once again, completely empty.

The full-screen API and its functionality are unchanged; only the interface is different. When an application supports full-screen mode, the green title bar widget contains a tiny zoom icon instead of the traditional plus sign.

Holding down the option key when clicking the green widget (or just double-clicking the title bar) will restore its pre-Yosemite appearance and behavior. If you don’t know what the pre-Yosemite behavior was, well, you’re probably not alone; it varied from application to application. Full-screen mode is the same everywhere—but not every application supports it. I’m all for interface simplification, but this is still not quite a solved problem.

Open/save dialog boxes

Open/save dialog boxes have dropped some weight in the toolbar region thanks to the removal of theiCloud/Mac mode switcher added in Mountain Lion. (TheiCloud Drive item in the sidebar replaces it.) The dialog box otherwise looks like a Yosemite-ized version of its former self, but there are a few new, hidden features.

Dragging a file from the Finder into an open/save dialog box will still cause the dialog to switch to the file’s parent folder (selecting the file if it’s an open dialog), just as it has done since time immemorial. Yosemite adds modifier keys to the mix.

Holding down the command key while dragging files to and from an open/save dialog will actually move the files. For example, command-dragging a file from the Desktop into an open dialog box currently showing the Documents folder will move the file from the Desktop to the Documents folder. Going in the other direction, command-dragging a file from an open/save dialog box to the Desktop will move it there.

The story is the same for option-drag, but the file will be copied instead of moved. Command-option-drag will make an alias of the file. All of this works for folders as well as files, of course. Finally, the context menu that appears when right-clicking (or control-clicking) an item in an open/save dialog now includes options to duplicate it or move it to the trash.

If you’ve been a Mac user long enough to rememberBoomerang, the popular open/save dialog enhancer for classic Mac OS, then you know Apple’s standard implementation of this ubiquitous interface element has always been somewhat lacking. Today, system extensions likeDefault Folder X continue to highlight its shortcomings. Yosemite’s open/save dialogs do not close that functional gap, but it’s nice to see Apple finally making some progress.

Apple menu

The Apple menu gets a minor reorganization in Yosemite. The separate “Software Update…” item is gone. Pending updates are now indicated with an in-menu badge on the “App Store…” item. The Dock menu item has also departed. Sadly, the System Preferences item still does not sprout a sub-menu to allow quick access to preference panes. In happier news, “About This Mac” is back to its rightful place as the sole item in a separate section at the top of the menu.

The case of the missing title bar

The earlierFinder screenshot contained all the expected parts at the top of the window: a title bar with its three stoplight widgets on the left and some title text (and a proxy icon) in the middle; below that, a customizable toolbar with groups of buttons. Now let’s look at the top of the Maps application window.

The stoplight widgets remain, but the title bar as we know it is gone. In its place is a toolbar that starts just to the right of the vertically repositioned stoplight widgets. In this case, the content of the window scrolls up behind the new title bar/toolbar hybrid and is faintly visible thanks to in-window blending.

The most obvious advantage of this new arrangement is its compactness. The traditional title bar takes up roughly 22points of vertical space and usually contains only the window widgets, some title text, and maybe a proxy icon. The wider the window, the larger the proportion of empty space in the title bar.

The new combined arrangement reclaims that vertical space for use by window content. Mac screens are almost always wider than they are tall, so vertical space tends to be more precious than horizontal space. According to Apple, “content-focused” design is another theme of Yosemite. Where possible, the visual and conceptual weight of the user interface is minimized and the content gets more space and emphasis.

The disadvantages of this design are also obvious. All the empty space in the traditional title bar actually served a purpose—providing a safe place to grab the window for dragging. The compact design drastically reduces the draggable area.

The empty space around the central set of toolbar items in the Maps screenshot above is an attempt to alleviate this problem, but it works best when the window is very wide. Maps addresses this problem by mandating a minimum width for the window. Safari, another application that uses this design, will hide toolbar items as the window gets narrower, shunting them off to a chevron pop-up menu.

There’s also a cruelly tempting 4-5 points of draggable vertical space above the toolbar items (and below the point where thewindow resizing cursor appears). For years, Chrome on the Mac has had a similar title-bar-less design, but with roughly double the vertical space available for dragging above the line of tabs.

I’m all for conserving vertical space, but I don’t like the idea of window movement gradually turning into a draggable region scavenger hunt.

Let’s not forget the other function of the traditional title bar: displaying the window title. Document windows should show the document name as the window title and therefore shouldn’t adopt the compact style that removes the title entirely.

The choice is less obvious for non-document windows. The Maps application puts the search field where the window title would be. This is a reasonable alternative to a static window title like “Maps.” It is a bit confusing, however, that the name shown in the Window menu is based on the current map location, which usually doesn’t match the text in the search field. Safari puts itsnewly neutered address/search bar in place of the window title, but it mostly sidesteps the window title problem by showing an intelligently truncated version of the page title on each tab.

For predominantly single-window applications, there’s often no sensible window title other than the application name. Apple’s solution for those applications in Yosemite is even more extreme. Compare the Notes application in Mavericks and Yosemite.

Notes in Yosemite incorporates the window widgets into the leftmost sidebar and surrenders the rest of the space traditionally occupied by the title bar to application content—visually, anyway. There’s still the usual amount of empty space at the top of the window available for dragging; it just happens to be styled to match the various regions of application content below it.

Despite maintaining the same draggable area, some vertical space is saved by allowing window content to nestle up against what would normally be the hard dividing line between a traditional title bar and the window content. In other words, the margin above the window content has been collapsed.

This is a clever design with fewer compromises than the combined title bar/toolbar used in Maps and Safari, but it still has some pitfalls. The lack of a clear division between window content and the title bar can lead to failed drag attempts when the cursor lands just below the valid draggable area. This design is also only feasible for applications that are not document-based and usually show just a single window. Luckily, many such applications are bundled with OS X.

All these title bar configurations are available to third-party developers via new window properties and APIs. These can be arbitrarily mixed and matched to create new designs beyond what Apple has done.

Overall, this monkeying with the title bar seems like a milder version of Apple’sinterface experimentation in Lion. In both cases, bundled applications are the test subjects. In Yosemite, however, the new features are immediately available to third-party developers as well.

Applications

Every application seems new in Yosemite thanks to the system-wide visual overhaul. Many applications have been rearranged to take advantage ofnew title bar configurations. And a few have been given entirely new interfaces. Here are some of the highlights.

Safari

Yosemite ships with Safari 8, the most substantial visual update to Safari since theabortedSafari 4 beta’s “toppy tabs.” We already covered most ofthe changes to Safari’s toolbar, but tabs add an unexpected twist. Since Safari uses in-window blending, changing tabs within a single window immediately changes the content scrolling up “behind” the toolbar. This means the same window can change its appearance in dramatic ways as you cycle through tabs.

There’s a new option (enabled by default) to showSpotlight suggestions in Web address search results. This includes the full range of possible Spotlight sources (Wikipedia, iTunes media and apps, map locations, movies currently in theaters, etc.), but only the top result is shown in Safari.

One more new toolbar-related feature will surely raise some geek eyebrows. When the combined address/search bar does not have the input focus, it no longer shows the full URL of the current page. Instead, it shows just the domain name (e.g., apple.com) or, if the current page was loaded via SSL with anextended validation certificate, a padlock icon and the organization name associated with the SSL certificate in green text.

The new address bar looks nearly identical to the one in Safari for iOS. On an iPhone, horizontal space is so constrained that the choice not to show the full URL is understandable. On an iPad, this is less true, but there’s an argument to be made for consistency. On the Mac, however, horizontal space is abundant, andpixel-for-pixel symmetry with iOS is decidedly out of fashion.

There are at least two other reasons to bring this interface to the Mac, however. The first is security. When the full URL is shown, it’s possible to fool users into thinking they are on a familiar website when they’re actually on aphishing site. One way to do this is by using a very long domain name that happens to begin with what looks like a legitimate domain name. For example, in the screenshot below, the URL may appear at first glance to be a Google search, but it’s actually a very long subdomain of my-malicious-site.com (which is not visible because the address bar is not wide enough).

Apple is not the first browser vendor to consider drastic measures to address this issue. Googlerecently experimented with replacing the URL with what it calls an Origin Chip.Google’s explanation of this change cites both security concerns and the precedent set by iOS.

All major desktop browser vendors, including Apple, have existing features meant to combat URL-based phishing attacks. These features usually add new elements to the address bar that cannot be faked by confusing URLs (e.g., a separate badge showing the owner of the site’s SSL certificate). Some browsers also display the domain and path portions of URLs in different text colors or weights. But all of these approaches suffer from the same problems that enable the very phishing attacks they’re meant to prevent: inattention and confusion. The people who don’t notice or don’t know how to interpret these subtle signs are exactly the people most in need of help.

This leads to the second reason to bring the iOS-style address bar to Safari on the Mac: simplicity. Though we technology enthusiasts may consider URLs an integral and well-understood part of our Web browsing experience, the vast majority of people have little interest in URLs beyond the one part of them that is commonly understood: the domain name. Everyone knows what google.com is, but few people know or care about the alphabet soup of text that may follow the domain name.

If you accept this premise, the iOS-style design follows naturally. Rather than adding elements to the address bar or trying to visually differentiate the components of the URL, Apple has chosen to reduce the visible address to the one part that people understand—which also happens to be the one part that matters when it comes to avoiding URL-based phishing attacks.

If you don’t accept this premise, well, chances are good that you know a bit more about computers than the average person—but that doesn’t necessarily mean you’re wrong. I confess, I also have my doubts about the complete irrelevance of URLs. Even if most people don’t understand the details,good URL design can and should use the address bar to convey location information beyond just the domain name. This is especially true given the dismal state ofpage titles on the Web, thanks both toSEO and general laziness.

Either way, I think all parties can agree on one thing: Apple should at least include an option to display the full URL for people who really do need to see it (e.g., Web developers). Happily, that option does indeed exist in the “Advanced” section of Safari’s preferences. Unhappily, this option does not allow the address field to get any wider. As discussedearlier, some amount of empty space in the toolbar is needed to provide a reasonable drag target for moving the window. The address field does get wider along with the window, but even with the default flexible spaces removed from the left and right sides of the toolbar, the address field stubbornly refuses to take up much more than 40 percent of the width as the window expands to fill the screen.

Also, even with the “full website address” option enabled,favicons are not visible unless the address field has the input focus. And like other search fields in Yosemite, the address field center-aligns its contents when it doesn’t have the input focus, but it switches to left-aligned (with an animation) when it gains focus. This makes for a lot of sliding around and waiting in a field that some people (e.g., Web developers) use many, many times a day.

Safari 8 has a few more new settings to tweak. There’s now a separate preference for what Safari should do on startup: open a new window or restore all windows from the previous session. As in the recent Safari 7.1 update, theprivacy-focusedDuckDuckGo joins Google, Yahoo, and Bing as a search engine choice in Safari 8.

WebGL has graduated from the Developer menu and is now enabled by default. Allowing webpages to execute code on the GPU presentsmany newsecurity challenges. Apple claims to have met these challenges by revising its graphics drivers to be resilient in the face of malicious or just plain buggy code. It’s taken Apple a long time to get here; WebGL wasadded to WebKit five years ago. As with otherSafari plug-ins, WebGL can be controlled on a per-website basis. It can also be disabled entirely in the Security section of Safari’s preferences.

[Update: An earlier version of this review stated that Apple had softened its stance onthird-party cookies in Safari 8. This is not the case. The default “Allow from websites I visit” setting in Safari 8 behaves the same as the default setting in Safari 7. It’s just differently worded. We apologize for the error.]

Safari’s new cookie-handling setting, “Allow from current website only,” will only accept cookies whose domains match the sending website. This is somewhere between the default setting (“Allow from websites I visit”) and completely blocking all cookies.

Private browsing is no longer a mode in Safari. Apple has adoptedGoogle’s approach to this feature, right down to the keyboard shortcut (command-shift-n), by adding a “New Private Window” option to the File menu. Private windows are distinguished by the dark gray background in their address fields.

Private windows prevent Safari from recording visited pages, search history, and text entered into forms. For Safari as a whole, the “Clear History and Website Data…” option in the History menu now offers several (also Chrome-like) options to limit the time span of the operation.

Though I didn’t get a chance to test these claims, Apple is touting Safari’s ability to browse the web for two hours longer than Chrome or Firefox on a single battery charge. Furthermore, thanks to its “native” support forNetflix playback (i.e., without having to install any plugins), Apple claims Safari has a three-hour advantage over Chrome and Firefox when watching videos from this service.

As usual, the new Safari provides a nice speed bump over the old version. The most significant new optimization is in the JavaScript engine. Safari 8 uses theLLVM compiler back end to optimize JavaScript code that has executed frequently enough to make the compilation time worthwhile. The WebKit development team has posted adetailed technical overview of this new system, dubbed the Fourth Tier LLVMJIT, or FTL for short. This, along with the three preexisting optimization tiers employed by WebKit, highlights just how much engineering time and effort goes into making adynamic language like JavaScript execute quickly. (This will be relevantlater.)

Mail

Mail is spared any radical title bar changes. It mostly looks like its old self, save for the expected translucent sidebar, subtly redesigned toolbar images, and, of course, all the new standard controls.

Yosemite’s new placeholder for people with no associated photo in your Contacts database is a circle containing the person’s initials. For example, the “AD” in a circle in the screenshot below is short for Apple Developer, the sender of the selected e-mail. The initials might seem silly, but some information, even if it’s not uniquely identifying, is an improvement over a generic silhouette of a human head.

Mail got a bit of a black eye in Mavericks thanks to some bugs that specifically affected Gmail users. Acouple ofpatches eventually set things (mostly) straight, but the basic mismatch between the organizing principle of Gmail (each message may have multiplelabels) and Apple Mail (each message resides in a single folder) remains a source of UI friction.

To burnish Mail’s reputation, Apple is promoting two new features added in Yosemite. The first solves one of the longstanding problems with e-mail: widely varying limits on large attachments. Every e-mail service is different, and there are often limits on both the sending and receiving ends. Even the most dedicated follower of the tech industry can’t be expected to memorize and track these limits across all e-mail providers.

Tech-savvy users can easily sidestep the issue by uploading large attachments to a file-sharing service that providespublic URLs, e-mailing those URLs instead of the attachments themselves. But this is a multi-step process, the start of which may require some software to be installed. Those of us who have tried walking someone through this procedure over the phone quickly learn just how much we take for granted when it comes to such “simple” workarounds.

Apple’s solution in Yosemite Mail is close to ideal. The new Mail Drop feature transparently uploads attachments to an Apple server and sends a text link in the e-mail instead of the file. From the sender’s perspective, none of this is visible. Both the attachment process and the appearance of the attachment in the e-mail are identical with and without Mail Drop.

Mail Drop itself has some limits, but they are high. Each individual attachment is limited to 5 GB, and attachment links will only remain active for 30 days. (The exact link expiration date is displayed in the e-mail.) Mail Drop is enabled by default for all iCloud e-mail accounts, but it can be used with any e-mail account.

If the e-mail recipient is also using Apple Mail on Yosemite, attachments are downloaded automatically and displayed just as if they had been attached in the traditional manner, rendering Mail Drop completely invisible to both the sender and the receiver.

Mail Drop is free, but attachment sending is only exposed through Yosemite Mail. It’s easy to chalk this up to Apple’s traditional allergy to Web applications, but I’m not sure the world really needs anotherWeb-based e-mail attachment service. The beauty of Mail Drop lies entirely in its integration with the Mail application.

The second major feature Apple is promoting as part of Mail in Yosemite is called Markup. It provides a way to annotate attachments directly within the message composition window. Any attached image or PDF can be annotated. (In case you’re worried, annotations do not affect the original attachment; a copy is made behind the scenes.)

The annotation tools are simple but cover many bases: freehand drawing, basic lines and shapes, formatted and styled text, and camera-scanned or trackpad-traced digital signatures. The Markup interface is displayed inline, surrounding the attached image. When annotating an image that’s too large to fit within the message window, a separate floating window appears.

If Markup seems appealing, you’ll be glad to learn that it’s actually a system-wide service based onYosemite’s new Extension system; it’s available in any application that uses Apple’s standard text controls. Mail just happens to be an ideal place to demonstrate its utility.

Finder

As seen inearlier screenshots, the Finder has gotten the standard Yosemite makeover: translucent sidebar, new-style toolbar buttons, a new application icon, the works. iCloud Drive (coveredlater) is the most obvious functional change. AirDrop (coveredlater) is also much improved. There’s one more interesting feature left to cover here.

It’s not hard for a programmer to create aquick, incredibly dangerous way to batch rename files. For everyone else, much safer third-partyfile-renaming applications have been around for ages.

This year, Apple has decided that renaming filesen masse is an important enough task that the Finder ought to be able to do it on its own. In the Yosemite Finder’s context menu, just below the option to compress selected files (and just above the increasingly irrelevant option to burn selected files to an optical disc) is a new “Rename…” option.

Note that this command is not available in the Finder’s main menus; it’s only in the context menu, perhaps as a nod toward its fringe appeal. Renaming options are limited when compared to hand-rolled or third-party options. When altering file names, the Finder can replace fixed text with other text, add text to the beginning or end of a file name (before any file name extension), and create file name sequences using a fixed string prefixed or followed by a number, a zero-padded counter, or the current date and time.

While most batch-renaming applications provide a comprehensive preview of the changes before they’re made, the Finder just shows one example filename. This example is updated in real time as the renaming options are modified. Luckily, if you make a big renaming mistake, the Finder’s Undo command will revert the entire operation.

Contacts

Contacts gets thetitle-bar-less Yosemite look with the obligatory translucent sidebar and the new circular contact thumbnail, but it is otherwise mostly the same as its Mavericks incarnation.

There are a few new preferences. The preferred short name format can be set to any combination of first and last names or initials, with a separate setting to use the nickname field, if present. If you know a lot ofMichaels or Jennifers, this feature will help… just as soon as Mac applications start using APIs that honor this setting, that is. Apple’s own Messages application will show nicknames but does not seem to use the short name format in message windows.

Game Center

The good news is that Game Center has finally shed itswood grain and green felt textures. The bad news is that the old design has been replaced by the abstract colored blobs introduced in iOS 7.

As in iOS, the blobs slowly jiggle and stretch. I find myself mesmerized by the animation, hopelessly trying to discern some meaning or purpose beyond a designer’s vague notion that shiny, brightly colored things communicate “fun.”

I used to point to the parlor games theme ofthe old Game Center as an example of Apple’s lack of respect for and understanding of video game enthusiasts. The blobs seem even further removed from engagement with gamers. Once again, I must conclude that this design is not for people like me. That’s fine for now, but excluding enthusiasts—the people most willing to spend their money on higher-quality products—is decidedly un-Apple-like. If Apple’sgaming ambitions ever extend to the high end, the view of gaming represented by these colored blobs will need to be revised.

iCloud

As in so many things, Google was ahead of the curve when it introduced theChromebook in 2011. It was a product that extended Google’s server-centric ethos to its logical conclusion. All code and data resided in the cloud; the Chromebook itself was merely a tool for accessing it. As the everyman narrator in the Chromebook’sintroduction video asked, “I could throw this thing into a river and not lose my stuff?” Google cut theGordian Knot of PC ownership hassles by making the hardware disposable.

But as in so many things, being too far ahead of the curve is often indistinguishable from being on the wrong path entirely. The Chromebook has not swept away the PC market of yesteryear… not yet, anyway. Native applications still hold sway over the computing world.

Apple has always playedyin to Google’syang, pushing native code and hardware/software integration over Web applications and server-side smarts. But Apple seems no less convinced of the merits of the Chromebook than Google. Everything good about the Chromebook is a hallmark of Apple’s approach to computing. The core tenet: simplification. The goal: freedom from worry.

Apple wants to have its cake and eat it, too: fabulous native applications, powerful hardware, and complete portability of data and identity. But instead of trying toleapfrog the rest of the industry (as it arguably did with the iPhone), Apple’s approach to this problem has been incremental—painfully so, at times. This march continues in Yosemite. One feature in particular takes a big step toward the Chromebook-like goal of having all your stuff everywhere, independent of any particular hardware device.

iCloud Drive

iCloud-savvy Mac applications have been able tostore their documents in the cloud for years, but as on iOS, each application had its own private location in iCloud that no other application could see. Furthermore, this location did notlook or behave like a normal location on disk; it was a lot more likeSpringBoard on iOS than a traditional Mac folder, allowing only a single level of nesting created by dragging one file onto another.

Protecting users from unrestricted file system access has undeniable usability benefits, as demonstrated by iOS, where this has been the law of the land since day one. On the Mac, however, adding a new, more limited model for file storage alongside the existing, traditional modelhas not been a clean win to say the least.

While direct interaction with the file system may still be where usability goes to die, history has shown that all it takes is one good anchor point to make things at least a bit more comprehensible. In the past, this anchor point was usually the desktop—the one place people knew how to reliably find. More recently,Dropbox has filled this role formillions of people.

As of Yosemite (and iOS 8), it appears Apple is finally on board with the “single anchor point” idea… mostly. Replacing the existingiCloud document storage is the new iCloud Drive—and I do mean replacing. There is a one-time process to upgrade to iCloud Drive. During the upgrade, all existing iCloud documents are copied to the new system. After the upgrade, changes made on pre-Yosemite Macs and pre-iOS 8 devices will not be visible in iCloud Drive. Conversely, any changes made in iCloud Drive are not visible on pre-Yosemite Macs and pre-iOS 8 devices. The two storage locations are completely distinct.

Upgrading is not mandatory, but iCloud Drive completely replaces the old “Documents & Data” item in the Yosemite’s iCloud preference pane. Applications like TextEdit and Preview won’t provide access to any form of iCloud document storage in Yosemite until iCloud Drive is enabled. You’ll be prompted to upgrade during the account setup process. If you decline, you can upgrade later by enabling iCloud Drive in the iCloud preference pane.

iCloud Drive is just what it sounds like: a single location for storing documents in iCloud. All iCloud-enabled applications can see the entire iCloud Drive, and there is no special limit on the number or depth of folders that can be created within it.

iCloud Drive even appears in the Finder sidebar just like any other file system location. But click on it and you may be dissuaded from the notion that iCloud Drive is a straight Dropbox clone.

For starters, the actual location of iCloud Drive in the file system is carefully hidden. Command-click the window title or use the Finder’s Get Info command to try to get a real file path and you’ll see only “iCloud Drive” as the top-level location. You can’t even drag the iCloud Drive proxy icon from a Finder window’s title bar into a Terminal window to get a file path. Applereally doesn’t want people knowing where on disk the iCloud Drive data lives.

More weirdness lurks. At the top level of iCloud Drive, badged folders appear for each iCloud-enabled application. You can’t Get Info on these folders either; the Finder just beeps in protest.

As it turns out, everything is still under~/Library/Mobile Documents/ in obscurely named subdirectories, but the careful subterfuge emphasizes Apple’s desire to keep iCloud Drive abstract. It isnot just “a folder that syncs.” It’s not a folder at all; it’s “iCloud.”

Deleting a file from iCloud Drive presents a warning sheet explaining that the file will be removed from all synced iCloud devices and put into the local Trash on this Mac. Moving a file out of iCloud Drive displays a similar warning.

These warnings are a good way to remind users that what look like standard file manipulations in the Finder may actually have far-reaching effects on other devices. But they also serve to further emphasize the odd nature of iCloud Drive. Dropbox has gotten by without these kinds of warnings for years. (On the other hand, this kind of integration with the Finder is much harder for anyone but Apple to do.)

Rather than adding tiny badges to file icons (as Dropbox does) to indicate the synchronization status of files in iCloud Drive, the Finder shows the sameprogress bars it uses for file downloads from Safari and the Mac App Store.

Propagation times are reasonable, if not lightning-quick. It can take a few seconds for changes made to iCloud Drive on one Mac to appear on another. Large files show a small iCloud icon and a progress bar during upload to iCloud Drive on the origin machine. Only once the file is completely uploaded does it start to download onto other Macs.

During these uploads, downloads, and brief wait times, there’s no global indication of iCloud Drive’s state. Is iCloud Drive completely up to date? Is it in the process of uploading or downloading one or more files? If so, how much work remains? A menu bar icon like Dropbox’s or, at the very least, a spinner next to iCloud Drive in the Finder sidebar would be nice. These are not esoteric technical concerns. Knowing when it’s safe to put a laptop to sleep or leave a coffee shop’s Wi-Fi is an important part of any network-based file storage system.

The drive to succeed

For years, Apple has stubbornly refused to treat iCloud document storage like just another network drive. Protecting users from direct access to the file system was a big usability win on iOS, but it was accompanied by a huge reduction in functionality on the Mac. Optimists assumed Apple would eventually introduce a new, as-yet-unimagined interface that was as capable as files and folders but as simple as document management on iOS.

iCloud Drive is not that. Whether it’s an admission of defeat or a triumphant return to practicality and sanity is mostly an academic question. What matters is how much better it makes the lives of Mac users. Given how closely it mimics Dropbox and other popular cloud storage products (right down to having aWeb interface andWindows support), I think it will be welcomed with open arms—assuming its reliability and performance live up to the standards set by its competitors.

Family Sharing

Family Sharing,introduced in iOS 8, is a long-overdue acknowledgement of the way families actually use Apple’s products. If you’ve ever had an iPad thrust into your hands by a child, followed by a plea to enter your password to complete an App Store transaction, this is the feature for you.

Family Sharing allows purchases to be shared among members of a single household while still allowing everyone to have their own Apple IDs. Each family has one organizer and up to five additional members. All purchases by family members use a single payment method controlled by the organizer. The organizer and (optionally) any other adult family members can be given the power to remotely approve purchases made by children.

Being part of a family provides many more features, including shared photo streams, calendars, reminders, and location information, all of which are detailed in ouriOS 8 review and inApple’s own documentation. There are just a few additional nuances worth noting.

In the past, Apple did not allow very young children to have their own Apple IDs. This has obviously changed now. There’s a separate, dedicated interface for adding an Apple ID for a child, accessible through Family Sharing on Yosemite and iOS 8. You must be sure to use one of those interfaces,not the normal (and usually more prominent) “adult” Apple ID creation interface.

If you were impatient for this feature in years past and have already created Apple IDs for your very young children using falsified birth years, you’re out of luck. There’s currently no way to convert an existing Apple ID to a child Apple ID. The best you can do is change the birth years to make your children 13 years old. (In Yosemite, sign in with a child’s Apple ID, go to the iCloud preference pane, click Account Details, then go to the Security tab.) You’ll still be able to force those accounts to have their purchases approved, but you’ll have to remember to adjust their birth years annually to keep them from becoming adults before their time.

One final warning: an Apple ID can only start or join a family grouptwice per year. Presumably this is to prevent frequent family hopping as a means to quickly and easily share purchases among large groups. But it’s conceivable that normal people could run into this limit merely by fumbling through the setup process. In Yosemite, as in life, think carefully before starting a family.

Extensions

Before the dawn of the OS X age, the entire Macintosh operating system and all applications shared a single memory space. (Kids,ask your parents about it.) Any application could see—and modify—memory belonging to any other application or the operating system itself. TheINIT mechanism in classic Mac OS allowed code to insert itself into the memory image of the operating system during the boot process.

Though the INIT system started as something limited and undocumented, it evolved into a popular, officially supported way to extend the functionality of the OS. Third-party INITs abounded. WhenSystem 7 arrived in 1991, INITs evolved into Extensions, adopting the familiar (to Mac old-timers, anyway)puzzle piece appearance.

These icons marched across the bottom of the screen from left to right during system startup. Given the wide-open memory access in classic Mac OS, Extensions could and did alter the functionality of the Mac in profound ways. Among a certain set of Mac enthusiasts, it was a point of pride to have many rows of icons filling the startup screen.

This was all part of the same thriving culture of Mac customization that spawned the appearance theme movementmentioned earlier. By the mid ’90s, Macs could be hot-rodded within an inch of their (virtual) lives—and beyond.

As you might imagine, having multiple first- and third-party Extensions all vying to insert their own code into key points in memory was an easy way to destroy system stability. The exact set of Extensions—and the order they were loaded—could mean the difference between a functional Mac and one that didn’t even make it through the boot process.

Jeff Robbin may be better known today as the creator of iTunes (néeSoundJam MP). But to some of us, he’s equally revered as the creator ofConflict Catcher, a classic Mac application whose sole purpose was to manage Extensions and debug their conflicts by automatically enabling and disabling sets of Extensions across repeated reboots.

It was the best of times; it was the worst of times. While Mac users cursed the stability issues caused by classic Mac OS’s old-fashioned memory management, most had one or two favorite system extensions that they did not want to give up.

When Mac OS X finally arrived in 2001, there was much gnashing of teeth about all aspects of the new OS, including its vastly reduced capacity for customization. We all celebrated the stability provided by a modern OS withmemory protection, but that same feature presented a new barrier to the old style of ham-fisted system customization. Nevertheless, clever Mac developersfound new ways to get their code into other processes, and anew Mac customization scene started to emerge.

Apple hated this. The transition from classic Mac OS to Mac OS X was long and painful. Here were these third-party developers recreating the same unrestricted system of in-memory patching that Apple had just worked so hard to escape.Popular third-party extensions frequently appeared in the crash logs of Mac applications of all kinds, as well as the OS itself.

Even today, many of the officially supported extension mechanisms in OS X work by loading foreign code into the address space of another process. OS X gives each process its own memory space, of course, so a buggy extension can only harm the specific process it’s been loaded into rather than taking down the entire system (unless it’s akernel extension, but those are rare and increasingly restricted).

Perhaps because of the unavoidable risks of allowing unknown code into other processes, Apple has not added many officially supported ways to extend OS X throughloadable bundles or similar memory-sharing arrangements. Even something as common on OS X as a third-party menu bar icon is forced to use a less capable (but presumably safer) API than the Apple-supplied menu extras.

Afterthree decades, one thing is abundantly clear: people want to customize their Macs. If Apple doesn’t provide a safe way to do so, many people will choose the unsafe way. This is bad for everyone: Apple, users, and application developers. In Yosemite, finally, Apple has found a way forward.

Extensions in Yosemite

Offering further proof that Apple is not averse toreusingproper nouns from its own past, Yosemite supports a new way to add functionality to applications and the OS itself called Extensions. The name is just about the only thing shared with classic Mac OS Extensions, however.

For starters, OS X Extensions come bundled with applications; they cannot be purchased or installed separately.Though they are distributed inside an application’sbundle, Extensions are not just applications launched in a special mode. They are separate, purpose-built binaries, with their own containers,code signatures, andentitlements. A single application may include multiple Extensions.

By default, Extensions don’t have privileged access to the data managed by their containing application. An existing security feature calledApp Groups allows explicit sharing between related applications. Using App Groups, developers can create a shared storage area that can be used by an application and its extensions.

Developers must take care to coordinate access to the shared container. Unlike classic Mac OS Extensions, OS X Extensionsdo not occupy the same address space as the application or process they are extending. As you might have guessed based on the privilege separation described earlier, Extensions run in their own, separate processes. Even multiple instances of the same Extension are in separate processes. This means that an application and one or more of its Extensions may be running simultaneously. Therefore, it’s imperative that developers use one of OS X’sfile coordination or othermutual exclusion APIs.

Extensions are never launched directly by the user. Apple framework code is responsible for finding Extensions on the system and launching them in response to user actions. The system may launch an Extension even when its containing application is not running.

Extension processes are expected to be short-lived and mostly stateless. The system is very aggressive about killing Extensions when their work is done, allowing only a brief opportunity to save any dirty state.

Privacy settings still apply to an entire application bundle as a unit, including all Extensions contained therein. If the user allows an application to access Contacts data, for example, all Extensions contained in that application’s bundle will also have access to Contacts data. This policy may seem too broad, but the alternative is for a dialog box to appear for every Extension within an application that has already been given the relevant permission. I think Apple made the right choice.

Extensions bind to Extension Points, which mark the extensible parts of the system. Yosemite has four Extension Points, and therefore supports four kinds of Extensions.

• Share Extensions allow third parties to add their own applications to OS X’s pervasiveshare buttons. Previously, the online services and applications available as sharing destinations were entirely controlled by Apple and included only big names like Facebook and Twitter. Share Extensions level the playing field.

• Today Extensions appear in thenew Notification Center’s Today view. Apple calls Today Extensions “widgets,” as if we needed any more hints aboutDashboard’s eventual demise.

• Action Extensions are used to alter content within another application. TheMarkup feature that Appleadvertises as part ofMail is actually an Action Extension that can work in any application that includes graphics and supports the Action Extension Point. (Try adding an image to a TextEdit document to see an example.)

• Finder Sync Extensions allow third-party developers to express file synchronization status and control within the Finder. This should sound familiar to Dropbox users accustomed to seeing its icon badges and custom context menu items in the Finder. I’ll give you one guess how Dropbox has been adding this functionality to the Finder thus far, and one more guess how Apple feels about it. (Answers: “fragile, unsupported, in-memory patching” and “hates it!”)

Extension Points themselves are implemented in system frameworks. Yosemite does not support third-party Extension Points, so the four kinds of Extensions listed above are all you’re going to get until Apple adds more (or opens things up to third parties).

Share Extensions invoked within Safari have the ability to run JavaScript code within the current page to extract information from theDOM or to modify the content of the page before the Extension runs.

Action Extensions declare which kinds of data they can handle; they can appear in any application that deals with one or more of those data types. They can be used to view content in a new way or to edit content and then return the modified version back to the host application. An Action Extension’s interface can appear as a modal window or as a custom view directly within the host application. Action Extensions can even register themselves as being available as toolbar items, allowing them to appear in the standard “Customize Toolbar…” sheet for the host application.

A new Extensions preference pane (featuring a puzzle piece icon as a nice echo ofclassic Mac OS Extensions) provides a simple interface for enabling and disabling specific extensions. This is useful even if you never install a third-party extension, if only as a way to keep unused services out of your Share menu.

In OS X, Apple wants developers to think of Extensions as a way to expose a subset of their applications’ functionality throughout the system. This is an appealing concept, but it seems to preclude the creation of Extensions that exist for their own sake. Will the Mac App Store accept empty “stub” applications that only exist as vehicles for the extensions they contain?

The good news is that, technologically speaking, there is nothing preventing extensions from becoming standalone products if Apple ever decides to allow it. As notedearlier, Extensions are already completely independent entities that are merely hitching a ride inside an application bundle. As the number of available Extension Points expands—as I hope it will in future versions of OS X—Apple may want to reconsider its Extension distribution policies.

Age of Extensions

Back in 2006, at the height of the controversy over “Haxies” and other memory-patching system extensions in OS X, Iimplored Apple to add a clean mechanism for extending OS X in the handful of ways that were demanded by the largest number of users. My argument then was that the popularity of particular Haxies could help Apple decide where to add extension points to OS X. I drove this point home using a story I first heard fromLarry Wall:

When the University of California at Irvine campus was first built, they just put the buildings in. They did not put in any sidewalks; they just planted grass. The next year, they came back and built the sidewalks where the trails were in the grass. That’s what haxies are to the Mac software market. Haxies are those paths in the grass.

Haxies are long gone, but Apple has finally answered the call for an official extension mechanism for OS X. In three out of four cases, Apple is putting down pavement on paths it created itself.Share buttons have existed since OS X 10.8; Action Extensions are a spiritual successor toServices, which haveexisted since the NeXT days; the Today area of Notification Center wasjust added by Apple in Yosemite. Only Finder Sync Extensions find their origin in a popular third-party system extension implemented using dangerous techniques due to a lack of clean hooks from Apple.

Truth be told, these days I see far fewer “unsafe” system extensions in use on Macs, even those owned by the same kinds of technology enthusiasts who would have souped up their classic Mac OS systems with umpteen Extensions and appearance themes. Some of this is due to Apple’s efforts to discourage unsupported system extensions. As OS X has raced forward in terms of features and technologies, system extensions have frequently broken. It takes time and money to keep finding new ways to make these hacks work. Perhaps it’s justnot a viable market anymore for most developers.

Thankfully, Apple’s response to its apparent victory in the war against unsupported hacks has not been to lock the system down further, but to finally create, for the first time in the Mac’s history, a safe, supported mechanism for system extensions.

The new Extensions system is making me give all the existing memory-sharing extensions in OS X thestinkeye, especially the officially supported ones. Why should a buggy menu bar icon cause the entireSystemUIServer to crash? I really hope that Apple plans to replace each legacy extension mechanism with a new type of Extension Point.

As excited as we Mac users should be about Extensions, at least we’ve always had a relatively easy way to use memory-patching extensions. The only option iOS users have had is tojailbreak and seek out system extensions from the more shady corners of the ’Net. There’s good news for everyone this year; iOS 8also includes support for Extensions.

This is relevant to the Mac because Apple has intentionally made the APIs similar enough that developers can share a substantial amount of code between iOS and OS X Extensions of the same type. In a world where there are far more iOS devices than Macs, every little thing that makes it easier for code written for an iOS app to be reused on OS X is a good thing for the Mac software ecosystem.

Continuity

Continuity is Apple’s umbrella term for its new effort to improve the integration between Macs and iOS devices. Though Apple has steadfastly insisted that its dual-OS strategy is the appropriate way to maximize the utility of its Mac and iOS hardware lines, Continuity is a public acknowledgment that those two product lines are often used by a single person whose activities are not easily divided into two neat, non-intersecting silos.

Continuity in Yosemite encompasses several new features and technologies, most of which require iOS 8 on the other side of the great device divide. With both OS updates just a few clicks and $0 away, chances are good that at least one aspect of Continuity will make it tempting to upgrade both sides of your Apple hardware life simultaneously.

Handoff

Handoff takes aim at the difficulty of transitioning between devices while continuing to work on the same task. Imagine you’re composing an e-mail on your iPhone as you ride to work on the train. You arrive at the office, but the e-mail isn’t complete. You’d like to sit down at your Mac and finish the e-mail on your big, comfortable keyboard.

Most people reading this know it’s possible to save a draft of the outgoing message on the server and then launch Mail on the Mac, sync with the server, find the saved draft, and resume typing the message. To fully understand Handoff, you must accept that Apple thinks this perfectly functional interaction is not good enough, that it contains too much friction and too many steps.

Assuming you’re using a Handoff-capable e-mail application like Apple’s Mail on iOS and OS X, here’s how the same task could be accomplished. Upon arriving at your desk in the office, the Apple Mail icon appears in a single-item mini-dock to the left of the real Dock (or on top, if your Dock is on the side of the screen).

A similar icon also appears in the command-tab application switcher. Clicking the icon in the mini-dock or selecting it from the application switcher launches Mail (if it’s not already running) and displays a message composition window containing the exact e-mail message you were just composing on your phone, with the insertion point in the message area at the end of the text you’ve written so far.

This is the kind of thing that wouldn’t be out of place in apie-in-the-sky concept video from a technology company, but it’s real and it’s shipping today. When all the dots connect, it really is a neat experience. Now let’s talk about those dots.

To start, Handoff is proximity-based; it only functions when two devices are near each other. So there’s no concern that composing an e-mail on your iPhone while on vacation will cause an icon to appear next to the Dock on your Mac back at the office. Devices useBluetooth low energy (BTLE) to discover each other. If you’re not within BTLE range (a few hundred feet, at most), Handoff is out of the picture.

Handoff works between any combination of iOS devices and Macs (e.g., between two Macs or from an iPhone to an iPad) as long as they’re all running at least iOS 8 or Yosemite and are all logged into the same iCloud account. Applications must explicitly support Handoff. The two applications involved in a Handoff do not have to be the same on both devices, but they do need to be from the same developer. The “same developer” check is based onTeam ID as determined by examining code signatures, which means only applications sold through the Mac App Store or signed with a registered AppleDeveloper ID can participate in Handoff.

Each Handoff-enabled application must declare a set ofActivity Types representing the high-level tasks that can be handed off between devices. For example, composing an e-mail is a good Activity Type for an e-mail application, but typing the subject line of an e-mail is too specific. Activity Types are identified by strings written in the standardreverse DNS format (e.g.,com.apple.mail.compose) but also have human-readable names for display purposes. During use, applications must set the Activity Type based on what the user is doing at any given moment. The current activity is advertised to nearby devices via BTLE.

On the receiving end, applications can claim a set of Activity Types they are capable of continuing. Applications don’t have to claim the same activity types they create. Applications can also advertise Activity Types without claiming any.

Given these details, restricting Handoff to applications from the same vendor seems more like a policy decision than a technical limitation. But there’s still more than enough flexibility for a single vendor to create a suite of cooperating iOS and OS X applications. A large, capable OS X application that passes different Activity Types to different, smaller, purpose-built iOS applications—or vice versa—is a particularly interesting scenario.

During Handoff, each Activity Type is accompanied by a “user info”dictionary describing the activity. While this dictionary can contain numbers, strings, URLs, and arbitrary data blobs, it’s expected to be reasonably small and contain mostly state information rather than data. For Handoff exchanges that require more than a one-time, one-way transfer of a small amount of data, a bidirectional network stream can be set up between the two applications using an optional feature of the Handoff API.

In an interesting twist, Apple also allows Handoff between a native application and a website. When setting and advertising an Activity Type, an application can also specify a website URL through which the activity can be continued. If no native application on a system claims an advertised Activity Type, a Web browser icon will be shown instead. Clicking it will load the webpage where the activity can be continued.

(Even Web browsers must be modified to support Handoff. They must claim a specific Web-browsing Activity Type to be eligible to receive a URL via Handoff. Safari supports this, but your favorite Web browser may not, at least initially.)

Going in the other direction, native iOS apps can claim associated website domain names and receive Handoff activities from a Web browser showing a page on one of those domains. The website itself must also list the Team IDs and app bundle identifiers of the native applications that are allowed to continue one of its activities via Handoff. This list is stored on the Web server in a cryptographically signed JSON file that is periodically downloaded by the receiving iOS device.

Apple is infamous for its “lack of enthusiasm,” let’s say, for Web applications, so it’s somewhat surprising when any new API has a Web component. But so many native iOS and OS X applications are companions to websites (e.g., Facebook, Twitter, even Gmail) that this kind of integration is a natural fit for Handoff.

Handoff challenges

There’s no question about it, Handoff demos well. But if it hopes to become a pervasive part of computing on Apple hardware, like iMessage or push notifications, Handoff will have to overcome several hurdles. The OS version requirements are mostly just a delay, given how good Apple has gotten at convincing users to upgrade. But the Mac is a big part of Handoff, and its adoption numbers,though improving, still lag behind iOS.

Then there’s the developer component. Apple can spread a feature like FaceTime all by itself, but Handoff requires third-party developers to modify their applications. Because Handoff only works between applications that belong to a single vendor, it takes at least two modified applications per vendor to do anything useful.

The final challenge is related to developer adoption. Will Handoff really be a useful, widely appreciated feature in practice? Will it be worth a developer’s time to implement? Much of the appeal of an impressive demo is in the fantasy of ubiquity. “It will be so cool when I can easily transfer whatever I’m doing from my iPhone to my iPad or Mac!” If “whatever I’m doing” is modified by “…as long as I’m doing it in one of the tiny handful of apps that supports Handoff,” the scenario loses a lot of its luster.

Also keep in mind that a Handoff demo conveniently assumes intent. In the real world, engaging in an activity that’s eligible for Handoff while within BTLE range of another Mac or iOS device does not necessarily indicate an intention to transfer the task to another device. And yet each nearby device will dutifully sprout interface elements to make Handoff possible, if desired. Some people might find this kind of (literal)action at a distance a bit intrusive. If that’s the case, there’s a system-wide preference to disable Handoff in the General preference pane.

SMS in Messages

If you long to see the green message bubbles on your Mac that denote the shameful use of a legacySMS/MMS service, then Yosemite is the release for you.

The Mac will use your iPhone as a proxy for SMS communication, sending and receiving non-iMessage text messages through it. Both devices must be signed in to the same iCloud account, and there is a one-time verification process to allow a Mac to use a specific iPhone.

Arguably, this complete symmetry of compatibility between SMS,iMessage, OS X, and iOS devices should have existed from the very start of Apple’s messaging service. Well, now it does—or rather, it will when iOS 8.1 is released on October 20th. This feature will not work with any earlier version of iOS 8.

SMS support on the Mac is a small thing, but Apple really does consider it part of its overall Continuity effort in Yosemite. Continuity is not just about adding new features like Handoff that form bridges between platforms; it’s also about removing any unnecessary differences in capabilities, no matter how minor.

AirDrop

In the same vein asSMS support in Messages, AirDrop now works between iOS and OS X. It was a bit of an embarrassment for Apple to have an ad-hoc file transfer protocol called AirDrop on both of its platforms for a year without any interoperability between the two. That’s one more functional gap filled in Yosemite.

Personal Hotspot

Using atethered iPhone as the source of Internet access for a Mac is now a lot easier in Yosemite for the common case of a Mac and an iPhone that are both logged into the same iCloud account. (Likecross-device SMS, Personal Hotspot requires iOS 8.1 or later.)

A separate entry in a new “Personal Hotspot” section of the Wi-Fi menu lists all available Hotspots on devices using the same iCloud account. Signal strength, network type (3G, LTE, etc.), and the iPhone’s battery status are also displayed. Selecting a Personal Hotspot device does not require a password.

People logged into different iCloud accounts will still see the hotspot, just as they did pre-Yosemite. It will be listed alongside all the other available Wi-Fi networks, and a password will be required to use it.

When tethered, Yosemite will make some effort to avoid burning through your data plan’s usage limits, delaying nonessential downloads like software updates and network backups. To help preserve the iPhone’s battery, the hotspot connection will be dropped if the Mac becomes idle.

iPhone calls

The final leap in iOS and OS X integration is to allow Macs to be used for the one task that iOS devices have stubbornly reserved for themselves: making and receiving phone calls. No, Yosemite doesn’t add aSIM card and a cellular radio to your Mac (though that would be a wonderful idea, Apple). But Yosemite does allow a Mac to use a nearby iPhone’s calling capabilities. Once again, the currently active user on the Mac must be logged into the same iCloud account as the iPhone.

Incoming calls are displayed as custom notifications with options to accept, decline, reply with a text message, or set a reminder to call back later. Text replies are entered directly in the notification alert.

If the call is accepted, the Mac’s audio input and output are used. There’s never a need to touch the phone at all. Outgoing calls work in a similar manner.

Calls can be initiated from the Contacts application by clicking on the (slightly silly) land-line phone handset icon next to the phone number. ASpotlight search for a contact’s name also reveals the same interface directly within the search results window. The Messages application can initiate real phone calls in addition to its existing iMessage and FaceTime capabilities. In fact, any text that looks like a phone number can be called if the application supports Apple’s standard data format detection. Just select the phone number and then right-click to see an iPhone calling option.

This doesn’t just work in applications like TextEdit and Reminders where the text is editable. It also works in Safari on un-editable text in webpages. In this case, just selecting the text reveals a pop-up menu, no right-clicking needed.

Missed calls are displayed as notifications whose format is based on the FaceTime notification settings. Clicking on a missed-call notification banner (or the “View” button on a notification alert) will call back using the phone.

In practice, this phone calling integration is boring in the best sense of the word. Aside from matching the iCloud accounts on the phone and the Mac, there’s not much that needs to be configured. When the phone is on the same Wi-Fi network as the Mac, it is used for incoming and outgoing calls; when it’s not, it isn’t. And if you don’t want to use this feature at all, it can be disabled entirely in the FaceTime application’s preferences on the Mac.

CloudKit

Apple’snetwork file storage services and APIs have had a bumpy road these past few years. The integration ofCore Data, an API that long predatesiCloud and was originally created for local storage only, has been particularly troublesome. Appleimproved iCloud Core Data significantly in Mavericks, but it may have beentoo little, too late.

Developers whofound Apple’s offeringsunviable have long since had toroll their own solutions for cloud-based data storage and sync. In most cases, these alternatives have not resembled iCloud Core Data. Furthermore, they’ve often resembled each other in important ways. To understand why, first consider the design of Apple’s solution.

Core Data is a framework for managing a set of related objects representing the information managed by an application. For example, an application for school enrollment might have objects representing teachers, students, and classrooms, with the expected relationships between them: one teacher per classroom, many students per teacher, and so on.

Core Data allows developers to model and manipulate these items and relationships as objects in memory. The Core Data framework itself is responsible for both initializing the state of theobject graph when the application is launched and preserving any changes made by the application, whether on the local disk or across the network in iCloud.

The alternative cloud storage and sync solutions that third-party developers arechoosing or creating on their own tend to do much less. Instead of just manipulating objects in memory and allowing the framework to handle the details of persistence, popular iCloud Core Data alternatives often require developers to write explicit code to initiate data transfer and synchronization. Aspects of serialization (i.e., converting an object into a data stream suitable for sending across the network) and the details of conflict resolution are also often left up to developers.

Why would developers prefer an API that has fewer features and requires them to write more code? There are two easy answers: predictability and control. There are few things more frustrating to a programmer than working with closed-source, third-party code that isn’t working as expected. There’s a reason the word “opaque” appears inmany developercomplaints about iCloud Core Data. Even with iCloud out of the picture entirely, the black-box, we’ll-take-care-of-everything design of Core Data itself hashistorically prevented developers from implementing what they know to be more optimal solutions for their applications.

Over the years, Apple has worked to alleviate many of the performance problems and feature deficits cited by developers. It’s been enough to tempt some developers toreconsider Core Data, but the conversiondoesn’t always take. It seems that once developers get ataste of a more flexible, less prescriptive, maybe even—gasp!—platform-agnostic storage service, it’s hard to go back to iCloud Core Data.

Though Apple isn’t abandoning iCloud Core Data, it has finally recognized that bug fixes and performance improvements will never change the essential nature of the framework. To address the needs of developers who have rejected iCloud Core Data, Apple has introduced an entirely new framework and corresponding back-end service: CloudKit.

CloudKit maintains the most important advantage of any iCloud-based API: its authentication system is based on iCloud accounts, which most OS X users (and nearly all iOS users) already have and are automatically signed into. CloudKit also goes a step further, providing an identity service to OS X and iOS applications even if they don’t use any other aspect of CloudKit or iCloud.

This arrangement is the first big difference between CloudKit and iCloud Core Data. The underlying structures that make CloudKit work—user accounts, databases, records, etc.—are all exposed to the developer as directly manipulable components. While there are many convenience APIs built on top of these structures, the individual building blocks themselves also have public APIs.

Unlike Core Data, CloudKit is a transport API only. There is no support for local persistence. CloudKit is entirely focused on sending data to and from Apple’s servers. CloudKit queries work in the expected database-like manner, returning lists of records. When querying the server, applications can request only the changes made since the last connection (based on a “change token” issued by the server). If there are any conflicts, it’s up to the developer to write the code to resolve them.

If an application wants to work offline, it is responsible for tracking local changes in a cache, pushing those changes up to the server when a network connection becomes available again (resolving any conflicts if this fails), and then fetching the changes since the last connection and applying them locally.

Developers have complete control over this process, with no ambiguity about when and how data is transferred across the network. Compared to iCloud Core Data, CloudKit is, in many respects, a more primitive API. All its moving parts are laid bare, and all actions must be explicitly initiated by code that developers write. Developers wanted predictability and control; CloudKit provides it in spades.

But wait, there’s more. CloudKit supports both structured data (e.g., database records) and bulk data (e.g., large files). There are separate public and private databases. Public data is visible by all users of an application, even if they are not signed into an iCloud account. (Anonymous access is read-only.)

Privacy is heavily emphasized in CloudKit. Private data is accessible only to the user that created it. Even the developer of the application cannot access private data belonging to users. No user information is exposed by default. Any disclosure must be requested by the application and approved by the user.

If users opt into CloudKit’s discovery service, they can be found by other users of the same application by anonymous record ID (as exposed in a public database) or e-mail address. There’s also a bulk discovery mode to find anyone in your own Contacts database who also uses this application and has opted into discoverability.

Arbitrary queries for user accounts are not allowed. There is no way to find all users with e-mail addresses ending in “@apple.com,” for example. The discovery APIs are the only way to get user information.

Finally, to prevent applications from periodically running queries to check for new or changed information (burningbattery power in the process), CloudKit supports persistent server-side queries called Subscriptions. These queries are created by applications but are run on Apple’s servers in response to changes to the database. Any time some new data matches one of these queries, a push notification is sent to all interested devices. This notification includes information about the query that caused it to be sent.

Limits and pricing

Another benefit of using Apple’s cloud services is that they’re subsidized by all the other things Apple does to make money. This is how Apple is able to provide CloudKit for free to all registered OS X and iOS developers—within limits. As Apple’s developer websiteattempts to explain, CloudKit has separate limits for storage and data transfers which are further broken down into “assets” (i.e., large files) and database records. The limits start small but then grow for each new user of an application, topping out at 1PB for asset storage, 10TB for database storage, 5TB per day for asset transfers, and 50GB per day for database transfers.

Now the (potentially) bad news: theliteral asterisk and fine print on all of this reads, “If you need more capacity than the limits listed above,contact us.” The charitable interpretation is that Apple doesn’t yet know what it will have to charge to run this service for developers who have enough users and/or usage to hit the limits of the free service. The more cynical interpretation is that Apple wants the flexibility to charge whatever it thinks each developer can afford once an application is so successful that it hits these limits.

A more straightforward, transparent pricing model would go a long way toward making CloudKit less risky and more attractive to developers. Let’s hope Apple clarifies its intentions in the coming months.

CloudKit outlook

CloudKit isn’t just the network data storage API that developers have always wanted from Apple; apparently it’s also the API that Apple has always wanted for itself. BothiCloud Drive and Apple’s new iCloud photo library service (upon which the upcoming replacement for iPhoto is being built) were written from scratch on top of CloudKit. Looking at it another way, if CloudKit doesn’t work well, third-party developers won’t be the only ones suffering.

Apple’s ability to make sure its servers are always available and that they answer requests in a timely manner is still an open question. As anyone who’s ever gotten an inscrutable error or interminablespinner from anApple TV while trying to watch a video from the iTunes Store knows, Apple’s use of a network service does not necessarily ensure its reliability or speed.

The most reassuring thing about CloudKit is its design. It looks a lot more like a well-executed client library for a traditional Web service than a Cocoa API that just happens to have a network component. It’s still far from the cross-platform, multi-language ideal presented by Microsoft’sAzure Mobile Services, but Azure can’t hope to compete with the platform integration of CloudKit on OS X and iOS.

This overview has barely scratched the surface of CloudKit. Although the API exposes all the knobs and levers rather than hiding everything inside a black box, those controls connect to some sophisticated machinery. Implementing an API like this would be a substantial amount of work for any developer, and that’s without even considering the server side of the equation. This is a powerful counterbalance to any doubts about reliability or pricing. Like all good frameworks, CloudKit gives developers a huge head start, allowing them to spend less time on infrastructure and more time on implementing what’s unique about their applications.

Apple itself is betting the future of its own cloud-based services on CloudKit.iCloud Drive is a good start, but it still lives in the shadow of more mature, time-tested services like Dropbox. Overall, I’m optimistic. Apple’s cloud services may finally be on the right track.

Swift

Software development never stands still. But if there’s one gravitational force that holds sway over the entire profession, it’s thatabstraction increases over time. Progress is not linear—there have been periods of stagnation, great leaps forward, and plenty of setbacks—but the long-term trend is undeniable.

The first modern programs were written inmachine language: sequences of numbers often written inbinary orhexadecimal.Assembly language was a step up the abstraction ladder, representing data and instructions with symbols instead of the raw digits of machine code. Languages likePascal andC divorced themselves from the details of any specific CPU’s instruction set, providing a hardware-agnostic interface for programmers. Later still, languages likeJava andC# moved away from direct access to memory.

Apple has been around long enough to have spanned much of this history. Though theoriginal Macintosh, with its industry-defining GUI, was a technical marvel in 1984, a large portion of its operating system was written in68k assembly code. Apple’s preferred language for application development has been on a slightly bumpy road toward higher-level languages, moving from Pascal to C and C++, taking adetour into Java, and finally arriving atObjective-C.

Moving up the abstraction ladder does not mean the old, less-abstract languages disappear entirely. Small portions of OS X are still written in assembly code today. Larger portions are written in C and C++. The top-level frameworks that application developers use are mostly written in Objective-C. It’s a continuum, with ever-decreasing proportions of programmers and code at the lower levels. Ask a modern OS X or iOS developer to create a full-featured GUI application using only assembly language and expect to be laughed out of the room.

Programming languages and APIs have their own sort of inertia. Once a community and a powerful set of tools has built up around a language, it’s hard to make the next leap forward. This inertia was on my mind back in 2005 when Iwarned that Apple was in danger of falling behind the rest of the industry in terms of programming language abstraction, just as it had once famously—and nearly disastrously—fallen behind with its operating system, fumbling with the ill-fatedCopland project for years with nothing to show for it.

It took theNeXT acquisition and the return of Steve Jobs to finally give Apple a modern operating system. What would it take to get Apple to move beyond Objective-C? If Apple didn’t start thinking about its next move soon, I worried that it could find itself in another Copland-like jam by 2010, at which point I assumed all its competitors would have higher-level programming languages.

The year 2010 came and went and Apple was still flying high, thanks partly to its success in the mobile market where its low-level language gave it a performance advantage over its smartphone competitors. I wasappropriately chastened by my overly cautious timeline, but I neverthelessinsisted that the problem remained. Apple needed to do something.

This opinion faced widespread—andpredictable—opposition from many Apple developers, both inside and outside the company. But one very important person at Apple saw an opportunity to advance the state of the art and seized it. In July of 2010, coincidentally a month after myCopland 2010 revisited article was published,Chris Lattner, creator of Apple’sLLVM compiler infrastructure and then senior manager and architect in Apple’s Developer Tools Group, secretly began work on a new programming language.

Four years later, Lattner, now director of Apple’s Developer Tools Department, appeared on stage during theWWDC 2014 keynote and shocked thousands of assembled developers—and quite a few Apple employees—by introducing Apple’s new programming language for OS X and iOS:Swift.

Like the end of any good mystery, the announcement of Swift shed new light on past events. Synthesizedproperties,dot syntax,blocks,automatic reference counting,collection literals—all these additions to Objective-C over the years have, unbeknownst to us, traced the outline of a shape lurking just below the surface. In the case ofARC, it went far beyond appearances; the work was directly applicable to Swift.

I’m not going to take you on a comprehensive tour of Swift’s syntax or features. Apple has publishedThe Swift Programming Language, a free e-book that describes the language in great detail. Swift has beenchanging rapidly since it was announced; the e-book has been revised four times already. Though Apple makes some application binarycompatibility guarantees, it has explicitly promisednot to maintain source compatibility as the language evolves.

What matters most about Swift is spelled out in the first chapter ofThe Swift Programming Language. Swift is intended to be “the first industrial-quality systems programming language that is as expressive and enjoyable as a scripting language. […] It’s designed to scale from ‘hello, world’ to an entire operating system.”

Perhaps this mission statement is so grandiose—so preposterous, even—that readers are inclined to gloss over it or dismiss it. But it’s the key to understanding the design of Swift.

Such great heights

One part of Swift’s mission is easy to understand: it must move Apple’s development platform to the next rung on theabstraction ladder; it must be a higher-level language than Objective-C. That means memory safety by default, ending the era when even the most routine code was one badpointerdereference away from scribbling all over memory and crashing—or worse, silently corrupting—the application.

A higher-level language should also enable programmers to accomplish common tasks with fewer lines of code and less concern about unimportant details. The code below, which gets an alphabetical list of Apple employees under the age of 50, might be mistaken for a mutant strain of JavaScript or Ruby, but it’s actually Swift.

let ages = [    "Tim":  53,  "Angela": 54,  "Craig":   44,    "Jony": 47,  "Chris":  37,  "Michael": 34,]let people = sorted(ages.keys, <).filter { ages[$0]! < 50 }

Even given recent advancements likeARC andcollection literals, this code would be substantially longer if written in Objective-C—and the only guarantee of memory safety would be the programmer’s skill. The complete absence of pointers in the code above (and Swift’sbounds checking) provides substantially more safety.

Swift is a convincing high-level language. The basic data types include the expected varieties of numbers, Unicode-aware strings, arrays, and dictionaries, all of which have properties and methods, including literals.

if "hello".hasPrefix("he") {    var sillyFour = 5.predecessor()    ...}

Any type can be extended, including the standard types like strings and numbers. It only takes ahandful of lines of code to make an expression like99.bottlesOfBeer() print theexpected song for any integer value. It’seven possible to extend other classes that can be initialized from strings (e.g., aURL class), enabling code like"http://arstechnica.com".host to parse the string as a URL and return the host name.

High-level-language programmers should be feeling pretty comfortable by now, but it gets better. Despite its rich feature set, the Swift language itself is actually quite minimal. All the basic data types are not part of the language proper. They’re part of the Swift standard library that is loaded automatically by the compiler—and the Swift standard library is written in Swift.

All the string and integer literals and variables in the code samples above are using these basic types defined in the Swift standard library. There’s no artificial distinction between primitive and object typesas there is in Java, for example. You don’t have to ask for the “fancy” types that support associated methods and attributes; all Swift types do. From an external perspective, Swift is much closer to the “everything is an object” philosophy embodied by languages like Python and Ruby than it is to Java, let alone a lower-level language like C or C++.

Still not convinced? When Apple says Swift aims to be “as expressive and enjoyable as a scripting language,” it’s not joking. A text file containing the code below will runas expected.

#!/usr/bin/swiftprintln("Are you not entertained!?")

Think fast

Now comes the hard part. At its best, Swift may approach the conciseness and ease of use of a high-level language like JavaScript, butrecall theamount of work Apple (andothers) have put into trying to make JavaScript fast. And yet, for all their efforts, few would consider trying to write an entire operating system in JavaScript.

The same features that make high-level languages safer and easier to use also make them slower. Consider this line of code, which happens to be valid in both Swift and #"a-plus-b">var c = a + b // this needs to be fast

CPUs have instructions for adding two numbers together. Integer values in a low-level language like C must be explicitly declared as such and are stored in memory in a format the CPU is able to consume without modification. The reward for this approach is that C integers can be operated on directly by a CPU’sADD instruction. Said instruction is exactly what a C compiler will generate in response to some code that adds two integers.

In a language like JavaScript,var c is a valid declaration because JavaScript variables can contain any type of value: numbers, strings, objects, or nothing at all. A JavaScript compiler can’t just generate a native CPU ADD instruction based on the codea + b shown above, because it has no idea if the values contained in the variablesa andb are numbers at all.

If the type of value contained in a variable cannot be determined atcompile time, then this determination must be made atruntime. Furthermore, if it turns out that one of the variables involved does not contain a number, or if the two variables contain different kinds of numbers (e.g., an integer and a floating point value), yet more code must execute tocoerce the values into compatible forms.

In JavaScript, even the+ operator is up for grabs in thea + b expression. Ifa turns out to contain a string value, then the correct implementation of the+ operator is the one that doesstring concatenation, not numeric addition.

Remember, all this is happening while the program is running. Instead of executing a single ADD instruction that was generated at compile time, the JavaScript engine must run dozens, perhaps hundreds, of instructions just to figure out what it’s supposed to do.

Swift cannot possibly be an “industrial-quality systems programming language” if it takes dozens of CPU cycles to add two variables containing integers. The obvious solution would be to require every Swift variable, function argument, and return value to have an explicitly declared type, just as these do in C and Objective-C. Then the compiler would know exactly what the codea + b is doing and which+ operator to use.

That sounds fine, but in all the Swift code shown so far, there hasn’t been a single declared type. Two years ago, Ispeculated that full-fledgedtype inference—the ability to deduce the type of a variable without an explicit type declaration—might come to Objective-C. Instead we got Swift, which leans heavily on type inference to achieve its goals.

The variables declared in the Swift code below cannot hold values of any type, as in the equivalent JavaScript. Each Swift variable has a strictly enforced type that is inferred by the compiler based on the value assigned to it in the declaration.

var name = "Bob" // Stringvar cars = 2     // Intvar temp = 88.2  // Double

But there’s a wrinkle. Recall that these basic types are not part of the Swift language; they’re all defined in Swift code in the standard library. So while the Swift compiler may know the exact type of thecars variable, it’s still left with a more fundamental question: what the heck is anInt?

The compiler will process the standard library and compile the code that implements theInt type, so it knows thatInt exists, what methods can be called on anInt, and so on. But sinceInt is not part of the Swift language itself, how can the compiler know whether it’s safe to feed anInt directly to a CPU’s ADD instruction?

There’s an additional challenge. All of theoperations onInt are also defined in the standard library and written in Swift.Operator overloading is anoft-maligned language feature, but given how even the most basic types are defined in a library, and given how literals are automatically inferred to be one of these types, it’s absolutely necessary in Swift. Even a simple expression that adds two integers could not compile if Swift did not support operator overloading.

Revisiting thea + b example, imagine we have variables with anInt type combined with the+ operator, both of which the Swift compiler knows nothing about until it compiles the standard library. How can this possibly be as fast as C code adding two integers?

Let’s try defining our own Swift function to add twoInts and then pry it apart to see how it ticks.

func add(a : Int, b : Int) -> Int {     return a + b}

Theswiftc compiler produces the following assembly code for this function (comments added). (The__TF3add3addFTSiSi_Si label is the name the compiler generated for theadd() function; you’ll see more of these auto-generated names later. Theylook crazy, but don’t worry about them.)

__TF3add3addFTSiSi_Si:    pushq %rbp        ; standard function prologue    movq  %rsp, %rbp  ; standard function prologueaddq  %rsi, %rdi  ; add two 64-bit integers    jo    LBB0_2      ; jump to LBB0_2 if the addition overflowed    movq  %rdi, %rax  ; put the result in right register for returning    popq  %rbp        ; standard function epilogue    retq              ; return from the functionLBB0_2:    ud2 ; abort on overflow by raising an invalid opcode exception

Lo and behold, there’s that efficient ADD instruction (in bold). The system works—but how? To learn more, we’ll have to look at something between the Swift source code and the final assembly code. To do that, we need to know a bit more about how Swift code becomes an executable binary.

The Swift compiler infrastructure is based onLLVM. This is no surprise. LLVM wasquietly introduced to Apple’s technology stack seven years ago and has since expanded to become the foundation of its entire development stack, from compiler toIDE.

The assembly code shown above is for anx86-64 CPU. Generating this hardware-specific code isthe last step performed by an LLVM-based compiler. Before that, code is generated for a sort of fictional CPU—aLow-Level Virtual Machine. This code, known as LLVM intermediate representation (LLVM IR), is what the LLVM optimizer works on. The optimization of LLVM IR is language- and CPU-agnostic; improvements to this optimizer can benefit all languages and all target CPUs.

Here’s the process for compiling code for an x86-64 CPU usingclang, Apple’s LLVM-based C/C++ and Objective-C compiler:

Instructingswiftc to show the LLVM IR for our Swiftadd() function doesn’t illuminate much. You’ll see a call tollvm.sadd.with.overflow.i64, which is the LLVM equivalent of the x86-64addq instruction seen in theearlier assembly code. We want to know how the compiler makes the leap from adding two variables of typeInt to calling the fast, native 64-bit addition instruction, whether that’s in LLVM IR or in x86-64 machine code.

The Swift compiler introduces another step and another intermediate form into the compilation process: Swift Intermediate Language (SIL). Here’s the process for compiling Swift code for an x86-64 CPU usingswiftc:

Here’s the SIL codeswiftc generates for ouradd() function:

// test.add (Swift.Int, Swift.Int) -> Swift.Intsil @_TF4test3addFTSiSi_Si : $@thin (Int, Int) -> Int {bb0(%0 : $Int, %1 : $Int):  debug_value %0 : $Int  // let a  debug_value %1 : $Int  // let b// function_ref Swift.+ infix (Swift.Int, Swift.Int) -> Swift.Int  %4 = function_ref @_TFSsoi1pFTSiSi_Si : $@thin (Int, Int) -> Int%5  %5 = apply [transparent] %4(%0, %1) : $@thin (Int, Int) -> Int  return %5 : $Int}// Swift.+ infix (Swift.Int, Swift.Int) -> Swift.Intsil [transparent]@_TFSsoi1pFTSiSi_Si : $@thin (Int, Int) -> Int

Thea + b code in the body of our function has been converted to SIL code that gets a reference to thefunction that implements theinfix operator for adding twoInts (you can see its declaration at the bottom), plus a call to that function on the two values passed toadd(). This code also reveals the name of the Swift standard library:Swift. TheInt type from the standard library isSwift.Int; the addition operator isSwift.+; and so on.

CallingSwift.+ to add two numbers together would be quite slow. The SIL shown above is the “raw” SIL. Certain SIL transformations are run byswiftc even when optimizations are disabled. The “canonical” SIL generated byswiftc for just theSwift.+ function is shown below (comments added).

// Swift.+ infix (Swift.Int, Swift.Int) -> Swift.Intsil public_external [transparent] @_TFSsoi1pFTSiSi_Si : $@thin   (Int, Int) -> Int {bb0(%0 : $Int, %1 : $Int):// Get a reference to the LLVMsadd_with_overflow intrinsic  %2 = builtin_function_ref "sadd_with_overflow_Word" : $@thin       (Builtin.Word, Builtin.Word, Builtin.Int1) ->       (Builtin.Word, Builtin.Int1)// Extract the two integer values from the Int structures of the args  %3 = struct_extract %0 : $Int, #Int.value  %4 = struct_extract %1 : $Int, #Int.value// Build the extra 1-bit int argument expected by sadd_with_overflow  %5 = integer_literal $Builtin.Int1, -1// Call sadd_with_overflow_Word to add the numbers  %6 = apply %2(%3, %4, %5) : $@thin       (Builtin.Word, Builtin.Word, Builtin.Int1) ->       (Builtin.Word, Builtin.Int1)// Extract the result from thetuple returned by sadd_with_overflow  %7 = tuple_extract %6 : $(Builtin.Word, Builtin.Int1), 0  %8 = tuple_extract %6 : $(Builtin.Word, Builtin.Int1), 1// Handle the case where overflow occurred  cond_fail %8 : $Builtin.Int1// Otherwise, wrap the result in a Swift.Int structure and return it  %10 = struct $Int (%7 : $Builtin.Word)  return %10 : $Int}

I know this code is getting a bit hairy, but hang in there. We’re about to get to the heart of the matter. Note the references toBuiltin in the SIL code above. Thesadd_with_overflow_Word function takes twoBuiltin.Word arguments (plus a 1-bit boolean). TheBuiltin.Word values passed tosadd_with_overflow_Word are extracted from theInt arguments passed toSwift.+.

Now we can see the rough outline of the bridge between the high-level world of theInt type and the low-level world of LLVM IR and (eventually) machine code. It’s notturtles all the way down. Inside eachInt structure is aBuiltin.Word whose characteristics are sufficiently well-specified that there is a direct analog in LLVM IR.

The canonical SIL code for ouradd() function reveals the final piece of the puzzle. It contains the inlined code for the entireSwift.+ function:

// test.add (Swift.Int, Swift.Int) -> Swift.Intsil @_TF4test3addFTSiSi_Si : $@thin (Int, Int) -> Int {bb0(%0 : $Int, %1 : $Int):  debug_value %0 : $Int  // let a  debug_value %1 : $Int  // let b// Swift.+ infix (Swift.Int, Swift.Int) -> Swift.Int inlined below  %4 = builtin_function_ref "sadd_with_overflow_Word" : $@thin     (Builtin.Word, Builtin.Word, Builtin.Int1) ->    (Builtin.Word, Builtin.Int1) // user: %8  ...  %12 = struct $Int (%9 : $Builtin.Word)  return %12 : $Int}

This automatic inlining is controlled by thetransparent attribute, which you might have noticed attached to theSwift.+ function in the earlier code samples.

Now, finally, we have all the pieces.Builtin is the gateway between Swift andLLVM IR. The types and functions exposed byBuiltin have direct mappings totypes andinstructions in LLVM IR. Thetransparent attribute denotes functions that are primitive enough that they should always be inlined. Generating LLVM IR from SIL code that usesBuiltin types and callsBuiltin functions is straightforward:Builtin.Word is anLLVMi64 (or an i32 when targeting a 32-bit architecture; SIL is more target-independent than LLVM IR);sadd_with_overflow_Word is thellvm.sadd.with.overflow.i64intrinsic function, and so on.

This exploration has revealed something else. The Swift standard library actually is a little special (beyond just being loaded by default). Though it is indeed written in Swift, the standard library is the only thing that has access to the world ofBuiltin functions and types. It also uses thetransparent attribute to mark certain functions for automatic inlining.

Since the source code for the Swift standard library is not public, we had to discover these things by examining the SIL generated from our Swift code. But rest assured,Builtin andtransparent are part of Swift itself, not just SIL. Runningstrings on theswiftc binary buried inside theXcode 6 application bundle exposes a-parse-stdlib option that will compile Swift code under the same rules as the standard library, allowing the use ofBuiltin types and functions. Similarly, adding a@transparent attribute to a Swift function will ask for it to be inlined.

All these features are undocumented and are confined to the Swift standard library for a reason. They are not part of the public face of Swift, but they are necessary for the language to achieve its goals.Builtin in particular provides an essential connection between the high-level world of Swift types and the low-level world of LLVM IR. If the Swift standard library does its job well, developers writing Swift code can be blissfully unaware of the techniques it uses to ensure speed and efficiency.

Whither SIL?

It’s worth considering why SIL exists at all. Though our simple integer addition example doesn’t demonstrate it, there are new kinds of language-specific, high-level optimizations that can only be done on a representation that retains more information than LLVM IR does about the source language.

Consider this Swift code, which uses the language’s support forgenerics:

func identity<T>(x : T) -> T { return x }func testInt() -> Int { return identity(42) }func testDouble() -> Double { return identity(42.0) }

Generating SIL for this code with optimizations disabledproduces a genericidentity() function and separatetestInt() andtestDouble() functions that call it. With optimizations enabled, the SIL codecontains specialized (and much shorter) implementations oftestInt() andtestDouble() that do not call through to theidentity() function at all.

This is the kind of optimization that any decent compiler for a language that supports generics would be expected to perform. It’s also the kind of optimization that would be awkward or impossible in LLVM IR.

Unlike LLVM IR, only a single language is currently converted to SIL as part of its compilation process. It’s right there in the name:Swift Intermediate Language. SIL code looks a lot more like Swift than LLVM IR looks like C or C++, going so far as to import the same libraries using the same names as Swift code. SIL is sort of a High-Level Virtual Machine (no, notthat one… orthat one), but it’s not designed to be a target for other languages. (Unlike theJVM andCLR, SIL exposesARC operations and therefore is not memory safe.)

As notedearlier, Apple has specifically stated that Swift’s syntax will change in the future. (Apple is likely to provide automated translation tools to convert old Swift code to the new syntax.) SIL provides a way to apply Swift-specific optimizations without adding unnecessary coupling between Swift’s syntax and the generation of LLVM IR. (Clang, which compiles C-based languages with substantially more stable syntaxes, generates LLVM IR directly from theAST.)

Despite the obvious benefits of SIL in its current role, a syntax-independent, high-level intermediate form with its own optimizer definitely seems like a technology with some potential. It’s possible that the larger purpose of SIL has not yet been revealed.

Frameworks integration

Swift may be an all-new language, but Apple has made sure it works with existing OS X and iOS frameworks. There’s a free e-book on this topic, too:Using Swift with Cocoa and Objective-C. Apple’s existing frameworks are written in C, C++, and Objective-C—languages that have pointers and direct access to memory.

Through a series of clever conventions (plus the use of Swift features likein-out parameters), most Objective-C APIs can be used directly from Swift code without dealing with pointers. Various Swift data types are also interchangeable with their Cocoa equivalents. Xcode auto-generates the appropriate header files so that Objective-C code can access Swift libraries. Apple even provides Swift translations of Objective-C API documentation.

Conventions and translation can’t cover everything, however, especially when it comes to lower-level C and C++ APIs. To support integration at this level, Swift does indeed support direct memory access through a family of pointer data types (with appropriately scary names likeUnsafePointer andCOpaquePointer). This is a necessary compromise, and oneshared by other memory-safe-by-default languages like C#.

Swift is too new—and was kept too secret—to have any major Swift-native frameworks or applications shipping in Yosemite, but Apple’s plans clearly point in that direction. While an application written in Swift may not seem any different to the user, a framework written in Swift—with Swift’s language conventions and features in mind—may look very different than even the most modern of today’s Objective-C frameworks. This is the world Apple is building toward, but it will be a long transition.

The shape of the future

Most people think of programming language design as an exercise in deciding what developers have to type to accomplish their goals. Debates may rage about features, semantics, security, and syntax, but the finished product is a language specification—or, at the very least, some reference documentation. This is what developers willjudge. Is the language too verbose? Are the semantics difficult to understand? Are there too manyweird corner cases? Too manyfunny characters? Are some featurestoo complex for their own good?

You can find debates like this about Swift all over the ’Net, many focusing on features that weren’t even mentioned here, likeoptionals andaccess control. Arguing about programming language syntax and semantics is a familiar, comfortable pastime for developers. Language designers might reasonably focus on these same concerns when creating a new language.

Swift is a little different. Yes, it was designed to be a language that programmers will find more productive and enjoyable than Objective-C. It was designed to provide important safety guarantees while remaining flexible and extensible. But Swift is also a language created by a compiler engineer.

The design of Swift did not start and stop at the things programmers have to type. It extends from the syntax all the way down to the machine code. Features were judged not just by the experience they provide to programmers, but also by the possibilities they enable or preclude in the compilation process. Swift is not an academic exercise. It’s not designed to be semantically pure or mathematically elegant. Swift is a language designed with its implementation in mind from day one.

This approach is not just a side effect of the personality, values, and skills of its creator. A focus on implementation is a necessary consequence ofSwift’s declared mission: to be as fun and expressive as a scripting language while also being as fast and efficient as a low-level systems programming language.

Swift is an attempt to create a low-level language with high-level syntax and semantics. It tackles the myth of theSufficiently Smart Compiler by signing up to create that compiler as part of the language design process.

The primary tool for ensuring Swift’s speed isstatic analysis—a technique with which the design team hassome prior experience. From type inference, which frees developers from manually annotating every variable declaration, to the multiple optimization passes done at the SIL and LLVM IR levels, the Swift language is made possible by the compiler’s ability to reason about the code without executing it.

Swift’s technique of lashing the most important parts of its standard library directly to LLVM IR primitives (via theBuiltin module) reveals the extent to which the language and its compilation environment are intertwined. Without these massive, invisible bolts screwing Swift’s basic types to the bedrock of LLVM (and, ultimately, to machine code), performance could not come close to that of C or Objective-C.

In some ways, this aspect of Swift’s design is akin to the “zero-cost abstractions” philosophy of C++. The difference is that Swift confines these low-level interactions to the standard library instead of exposing the guts of the system to all programmers.

Beyond its implementation, the developer-facing aspects of Swift do embody a specific philosophy about software development. I’ve been writing software professionally for 18 years, and I definitely have my own opinions about language design. For example, I find any coding done in service of the type system to bemostly wasted effort when writing high-level code that controls things like which window appears when a certain button is pressed or which data is fetched from or stored into a database.

Swift’s type inference alleviates some of this pain, but it doesn’t change the inherent static typing of the language. The choice between static and dynamic typing is not just based on the effects each approach has on compiler implementation. It’s also—perhaps even primarily—a philosophical choice about what constitutes “good code.”

Motivations aside, it’s the practical consequences of Swift’s design philosophy that make it resilient to my complaints. I admire Swift’s ambitious mission and I understand how essential each one of its features is to achieving it.

The strongest arguments against Swift are ultimately questions about that mission. Swift could be a much friendlier high-level language if it gave up on being an “industrial-quality systems programming language.” On the other side of the coin, Swift could be vastly simpler if it focused exclusively on being just “a better C.” Few languages have even attempted to do what Swift is doing. The degree of difficulty is high and self-imposed—in other words, a typical Apple move.

If this were an Apple keynote presentation, now is when Tim Cook might come back on stage and explain that “only Apple” could create something like Swift. While that would be a bit of an exaggeration (witnessC# and theCLR from Microsoft), a project like Swift is an excellent fit for both Apple’s ambition and its longstanding tradition of vertical integration.

It’s not a stretch to imagine that Apple’s plans for Swift extend from the source code all the way down to not just the machine code generated by the compiler but also the design of the CPU itself. At various times in the past, specific hardware features of PowerPC, x86, and ARM processors have influenced the efficiency of fundamental aspects of Apple’s platform, fromfunction calling conventions tofeatures of the Objective-C runtime. I would be surprised if Apple hasn’t already lobbied for (or directly implemented, in the case of its own chip designs) CPU features that are tied directly to its compiler, language, and runtime stack. I expect even more of this in the future.

Unlike Clang and LLVM, the Swift-specific parts of the compiler toolchain are not open source. Apple has the resources and influence to ensure the success of Swift even if it is the only company using it at scale (cf. Objective-C). Nevertheless, powerful factions within the company are undoubtedly in favor of making Swift an open source project. The push to release Yosemite and iOS 8 has likely taken precedence so far, but I expect this issue to be revisited.

Swift is the most important change to Apple’s development platform sincethe switch from PowerPC to Intel processors. Despite theexpected grumbling from experienced Objective-C programmers, it is not a lateral move. Swift is a significant step up in terms of safety, expressiveness, features, andperhaps evenperformance, all in its 1.0 release.

Swift is still very young, but it has a bright future ahead of it. If it succeeds, it has the potential to spread to every corner of Apple’s technology stack, from server-side programming to installer scripts—maybe even to the Web. But Swift’s role as the successor to Objective-C is important enough on its own. In a way that all past enhancements to Objective-C have not, Swift has the potential to ensure theviability of Apple’s development platform for decades to come.

Grab bag

When it comes to finding new details in the nooks and crannies of OS X, Yosemite’s sweeping graphical update is the gift that keeps on giving. Even after months of using Yosemite, I’m still routinely surprised by a new icon, cursor, or interface layout. There are plenty of minor functional changes as well. Here are a few favorites.

Activity Monitor

Earlier versions of Activity Monitor required a tedious mouse-over-and-wait action to see the URL associated with a Safari back-end process. The new Activity Monitor in Yosemite helpfully shows the URL in place of the unhelpful “Safari Web Content” process name.

Terminal

While third-party alternatives likeiTerm still offer many more features, the sturdy, dependable OS X Terminal application has always met my needs. It’s also an application that has, at times, had less than one whole Apple developer dedicated to it. These days, any change at all is noteworthy. The most visible addition in Yosemite is an in-window scrollback search interface that replaces the old, awkward dialog box.

Messages

In another refreshing instance of platform parity, Yosemite’s Messages application includes audio message support (click the microphone button to the right of the text input field) plus the ability to mute or leave a group chat. New participants can also be added to an existing group chat. If one or more people are sharing their location information with you, a map will appear in the “Details” popover with each person’s avatar correctly placed. Thumbnails of images sent as part of the conversation are collected at the bottom of the popover.

JavaScript automation

It’sbeen a while since the “open” part of Apple’sOpen Scripting Architecture has been meaningfully exploited;AppleScript is the only OSA language most Mac users know (if they know any at all). In Yosemite, Apple has stepped up to the plate and added aJavaScript OSA front-end based on WebKit’sJavaScriptCore engine. As a cherry on top, there’s a built-in Objective-C bridge, opening up the world of Cocoa and even plain old C to your humble JavaScript code.

System Preferences

Like the rest of Yosemite, System Preferences has received a nearly complete visual overhaul. The new preference pane icons are not quite as immediately appealing as the best of thenew application icons, but they are pleasant enough.

Notifications is the most changed, but I’m not sure it evokes its namesake any better than the old icon. Energy Saver has been upgraded from aCFL bulb to anLED. Apple still doesn’t quite know what to do with the General icon, but at least it looks familiar. The Date & Time icon is new, but the date still never changes from the 18th. (At least we now know what month it’s frozen in: July.) The Startup Disk icon still depicts a spinning hard disk despite the increasing prevalence of solid-state drives. Either way, it’s always been strange that Apple has chosen to use an image of a part from inside its computers as an interface icon. Likethe floppy-disk save icon, this bit of mechanical history may be with us for a while yet.

The newly combined title bar and toolbar now includes back/forward buttons. A grid of tiny dots replaces the “Show All” button text. Navigating with these three controls means passing back through the main screen each time you want to open a new preference pane. The back/forward buttons dutifully replay this history, with every other step showing the full set of preference panes. Moving directly from one preference pane to another using the View menu produces a more sensible navigation history, but who does that? I’m not sure how many people even know that menu exists.

If Apple wants to improve preference pane navigation, I’d much prefer a customizable toolbar that would let me add buttons for my most frequently used preference panes.

General

The new “dark mode” andHandoff checkboxes were mentioned earlier, but there’s one more change worth mentioning. The default Web browser is now selected here instead of in Safari’s own preferences.

Desktop & Screen Saver

A nice collection of photos from Yosemite National Park are included for your desktop viewing pleasure. In exchange, we have lost thehard-won setting to disable menu bar translucency, and the underlyingproperty list setting no longer seems to be honored. If you don’t care to see what’s behind your menu bar, goingfully opaque may be your only option.

Mission Control

As if we needed any more hints thatDashboard is not long for this world, the mission control preference pane now includes an option to turn Dashboard off entirely.

Security & Privacy

There’s a new setting in the Diagnostics & Usage section to control whether this information is shared with third-party developers in addition to Apple itself. Both options are checked by default.

The Location Services privacy list now covers System Services (currently just Spotlight Suggestions). There’s also a separate option, disabled by default, to display the location services menu bar icon when system services request location information.

Notifications

WhenDo Not Disturb mode is engaged, Yosemite no longer offers the option to allow FaceTime calls from your favorite people only; it’s everyone or no one. The customization options available in thenewly redesigned Notification Center replace the old setting to enable and disable Share Buttons in the Notification Center sidebar.

App Store

There’s a new option to install OS X updates automatically. Like the similar option for application updates, automatic OS updates are disabled by default. But something tells me it’s only a matter of time before both of those defaults are reversed.

Recommendations

Like iOS 7 before it, Yosemite is an aestheticone-way valve. Though the new appearance is not particularly radical, it’s so comprehensive that it quickly establishes itself as the new normal. Switching back to Mavericks after a week or two in Yosemite is like returning to iOS 6. Everything looks embarrassingly chunky, glossy, and gaudy. This will likely be true even if you havereservations about the wisdom of usingonionskin as a building block for a user interface.

The visual changes are also why Yosemite may feel like a more significant upgrade than Mavericks. For people who value being on the cutting edge of both fashion and technology, this will make Yosemite more attractive. For others, it will inspire some additional upgrade caution. Among the biggest curmudgeons,Mavericks may even become the newSnow Leopard: the last “good” release before Apple ruined everything.

In truth, Yosemite’s new look is not a signifier of any particular fitness (or lack thereof) for upgrade purposes. The standard rules apply. Don’t upgrade until all the applications you care about are compatible. Make sure you have good backups. Point-zero releases are always a little more risky. Wait for version 10.10.1 if you’re nervous.

I’ve been upgrading all my Macs sooner after each OS X release for the past several years and have not regretted it. When it comes to stability, it feels like Apple is really hitting its stride with these yearly releases. Mavericks has been very solid for me. I’m optimistic about the long-term stability and compatibility prospects for Yosemite. As for bugs like the MavericksGmail problems, I have some hope that thepublic beta program has helped root them out before release.

Myconcerns about scope remain. Yearly releases add administrative overhead, delaying features that take more than one release cycle to develop—some of which arealready overdue. That said, Yosemite’s new look was one such overdue change. I would not have wanted to wait any longer for it.

The mobile market continues to evolve much faster than the more mature PC market, providing ample motivation for iOS to continue on its aggressive schedule. With Yosemite, being in sync with the yearly iOS releases has become a lot more important.

One will, one resolve, one cause

The historic lack of integration between iOS and OS X is shocking in retrospect. The interactionconcepts andvisual treatments that did migrate from iOS to OS X tended to arrive asinvasive species. Some technology—but precious few ideas—moved in the opposite direction. Apple had let the dysfunction of itsorg chart leak through to its customers, and the results were not pretty.

Then camethe reorganization, with its promise to “increase collaboration” between groups.

The signs were all good, but it takes a long time to turn a ship as big as Apple.Mavericks was released in the middle of this course correction, remaining uncomfortably out of step with iOS.

Yosemite and iOS 8 are the first great victories for the newly collaborative Apple. The visual coherence between the products blessedly obsoletes the former one-way mimicry and reflects a deeper technological unity. Features likeHandoff that require cooperation in all stages of development, from conceptualization to execution, are evidence of an Apple that puts the needs of its customers ahead of departmental divisions.

The political and technical battles inherent in the former two-track development strategy for OS X and iOS left both products with uncomfortable feature disparities. Apple now correctly views this as damage and hassetforth torepair it. New features likeExtensions share as much technology as possible and appear on both platforms simultaneously.

Extensions are also a sign that old prejudices have departed with the old leadership regime. Once seen as a wart on OS X that iOS was lucky to be without, customization is now deemed important enough to be possible on both platforms—safely. The list of Things Apple Will Never Do is slowly being replaced by the list of Things Apple Has Done.

Then there’s iCloud, the one offering that can’t help but be shared among Apple’s platforms. Even here, the perceived stubbornness of the past has been lifted.CloudKit is Apple’s acknowledgment that its previous offerings did not meet the needs of developers. The extensive use of CloudKit in Apple’s own products reinforces the notion that this is not a grudgingly offered concession but a true change of heart.

The distinct Dropbox flavor ofiCloud Drive is another reversal of a longstanding policy. Copying the feature set and interface ofthe market leader is not a comfortable position for Apple, but sticking with a less-capable, less-popular alternative was worse for everyone involved. Apple has shown that it wants to succeed more than it fears being seen as a follower.

Viewed in isolation, Yosemite provides a graphical refresh accompanied by a few interesting features and several new technologies whose benefits are mostly speculative, depending heavily on how eagerly they’re adopted by third-party developers. But Apple no longer views the Mac in isolation, and neither should you. OS X is finally a full-fledged peer to iOS; all aspects of sibling rivalry have been banished.

The Mac today is just one part of a conceptually, organizationally, and (increasingly) technologically unified platform that spans fromwrist toworkstation. The hardware-based platforms of the past remain relevant to developers, but Apple seems determined to make them much less important to its customers. With Yosemite, the Mac has taken its first step into a larger world.