OS X 10.11 El Capitan: The Ars Technica Review

Poor OS X can't get no respect.

Apple's Mac operating system has been playing second fiddle to the iPhone since 2007, when Leopard was delayed to make more room for the then-new smartphone. And despite the occasional protest to the contrary, OS X hasn't been the apple of Apple's eye since then. It was second to iCloud, second to iMessage, second to the post-Scott-Forstall flattening of the operating system. And as an added insult, Apple couldn't find time at a two-hour product event to mention OS X or the Mac except in passing, mainly in the context of other platforms. We got a release date for El Capitan on the day of the event, but it was posted to Apple’s site, not mentioned onstage.

OS X is obviously still important to Apple's strategy—the one where the company wants to trap you so thoroughly in its ecosystem that you can never leave—but it doesn't get to lead the charge anymore.

The subtle difference in El Capitan is that we’re actually seeing new features come to both iOS and OS X at the same time rather than existing on iOS first and then trickling down to the Mac later. Many of the biggest, most noticeable changes here are the same ones you saw in iOS 9 two weeks ago. The new Split Screen multitasking mode, tweaks to multitouch gestures, changes to services like Spotlight , and overhauled apps like Notes all fall into this category. Others, like System Integrity Protection, are merely iOS-inspired.

Really, this is the first time in several years that iOS and OS X have felt like they’ve gotten (and needed) the same amount of attention from Apple—both get to spend a release in the slow lane as Apple puts its marketing muscle behind newer platforms like the Apple Watch and the new Apple TV. Like iOS 9 (and Mountain Lion, and Snow Leopard), El Capitan is about refinement. Yosemite’s big statement was “This is what OS X looks like now.” El Capitan’s is a relatively meek “Hey, I have a couple neat tricks to show you.”

Table of Contents

Installation and system requirements

It’s hard to believe, but this is the fifth download-only release of OS X, and the third to be released to Mac users totally free of charge. This year Apple is even releasing the new version of OS X Server for free to Yosemite Server users.

This is also the fourth straight release not to drop support for any older Macs, a refreshing change after several successive versions that kept trimming the support list. Leopard ended support for older G3 and G4 Macs, Snow Leopard dumped PowerPC entirely, Lion excluded 32-bit Intel Macs, and Mountain Lion dropped anything that couldn’t go entirely 64-bit.

The minimum system requirements, which haven’t changed since the Mountain Lion release in 2012, runs thusly:

iMac (Mid-2007 or later)
MacBook (13-inch Aluminum, Late 2008), (13-inch, Early 2009 or later), (12-inch, Early 2015)
MacBook Pro (13-inch, Mid-2009 or later), (15-inch, Mid/Late 2007 or later), (17-inch, Late 2007 or later)
MacBook Air (Late 2008 or later)
Mac Mini (Early 2009 or later)
Mac Pro (Early 2008 or later)
Xserve (Early 2009)

Not all of those Macs support all of OS X’s features. The cutoff for the fanciest features—AirDrop between Macs and iDevices, Handoff and Instant Hotspot, the Metal graphics API—require a Mac introduced in 2012 or later. Here’s the specific support list for all of those:

MacBook (Early 2015)
MacBook Pro (2012 or newer)
MacBook Air (2012 or newer)
Mac Mini (2012 or newer)
iMac (2012 or newer)
Mac Pro (Late 2013)

Metal is the only one of those features that’s new in El Capitan, and it's got its own section later in the review. Our Yosemite review has more comprehensive coverage of AirDrop, Handoff, and the other Continuity features introduced in that release.

To install El Capitan, you need a supported Mac running OS X 10.6 or later, and you need to be able to grab the multi-gigabyte installer from the App Store (the GM build is 6.07GB). Once you’ve downloaded the installer, it’s still relatively trivial to create a USB install disk you can use to perform upgrades and clean installs on multiple Macs.

The installer and first-time setup wizard don't change from their Yosemite versions. The only option you really have in the installer is which partition to install OS X to. When you set the OS up, you're prompted to enter an Apple ID, and if you do you're also asked (but not required) to link it to your local user account and use it to store a FileVault encryption key. Creating an all-local account and keeping your key to yourself are still options, though, even if you do want to use an iCloud account for syncing other data. Anything you decide you want to do later can be done in the System Preferences.

Welcome to San Francisco

The biggest refinement to Yosemite’s look is the introduction of Apple’s homemade San Francisco typeface, first used on the Apple Watch but also on the keyboard of the new MacBook and in iOS 9.

The change is subtle. Individual characters are generally taller and less wide than Helvetica Neue characters, though Apple appears to have tried to make the spacing and layout as close as possible so developers won’t have to make changes to their apps. It usually won’t be a problem, though as with the original switch from Lucida Grande to Helvetica Neue there may be some edge cases.

The place you notice San Francisco the most is in characters like the lowercase “e” or “a,” where San Francisco leaves a bit more space in the gap between the top and bottom parts of the letter. The uppercase G is also more rounded. That’s how close non-font nerds will need to look to tell the difference.

That said, San Francisco might actually help with readability on non-Retina displays. Since characters are generally narrower but taller, there's a very small increase in the amount of space between letters, and letters like "a" and "e" don't blur into themselves as much as they did in Helvetica Neue. The post-Yosemite UI is obviously optimized for Retina displays, but San Francisco helps keep the characters from blurring together the way they sometimes can on standard screens.

We noted this in our iOS 9 review, too, but it's more important on OS X. iOS 9’s ever-longer list of supported devices includes only two without Retina displays, but Macs going all the way back to 2007 can run El Capitan and Retina screens are definitely in the minority.

If you're interested in San Francisco, there's a good WWDC session available online or in the app that outlines the differences between the fonts included in both iOS 9 and El Capitan and the San Francisco Compact variant that ships on the Apple Watch. In short, the Compact version of San Francisco uses flat lines rather than curves on many letters to increase the amount of space between characters. The session also explains the differences between the Display and Text versions of San Francisco. Display is intended to look better at larger sizes, while Text is made to look better at smaller sizes. The operating systems automatically switch between the two, using Display at 20 points and above and Text at 19 points and below.

The rest of the UI's basic elements—buttons, sliders, icons—are pretty much where Yosemite left them, aside from the occasional tweaked icon. Colors and textures are brighter and flatter than in the pre-10.10 days, though OS X still retains drop shadows and other signs of depth that are more important to a windowed operating system than they are in iOS. Text fields and radio buttons are animated, icon designs exists somewhere in between their iOS 7 designs and classic OS X designs. Yosemite had more time to gestate than iOS 7 did, so Apple has less post-release fiddling to do with the way things look and work.

One small, additional change since Yosemite: the classic beachball icon was one of the final glassy elements in Yosemite, but in El Capitan it's gone flat. There are very few stones left to turn over here.

Window management: Mission Control and Split View

El Capitan's single most transformative feature is the overhaul given to Mission Control, a revamp that also affects Spaces and the Full Screen mode. It feels like a marriage of OS X's window management and some of Windows 10's more promising new features, driven by Macs' large, accurate trackpads. The fact that Windows 10’s window management and multitasking features borrow so much from the Mac means that comparisons are inevitable.

Start by swiping three fingers upward to open Mission Control. This should look broadly familiar save for a couple of tweaks. You don’t see thumbnails of all your open desktops and full screen apps at the top unless you move the mouse pointer up there, only text labels. And windows from the same app are no longer stacked atop one another by default, but displayed separately (this was an option in older OS X versions, it's just the default behavior now). If you have a bunch of Chrome or Safari windows open at once, you know this could be annoying in Yosemite—Mission Control becomes way less useful if you can’t actually see the window you’re opening. If you prefer the old behavior, you can still enable it in the Mission Control settings, but it's off by default.

You can still use Mission Control pretty much the way you did before. Switch between windows, open and close spaces, drag windows from one desktop to another, and drag spaces between multiple monitors. The biggest new feature is Split View, which places two full screen apps side by side in a way that looks a whole lot like that iPad multitasking feature from iOS 9.

There are a few different ways to do this. Long-click the green stoplight button of an app that supports full screen mode, and the OS will ask you to drag it to the left or right half of the screen. A mini-Mission-Control-type collection of your other windows will then fill the other half of the screen. Apps that can take advantage of Split View will look like they normally do, while those that can’t do it will appear faded. Click an app and you’ll see them both side by side, divided by a vertical black line.

You can also put an app into full screen mode as you normally would, open Mission Control, and drag another full screen app over top of the first app to create a Split View. Unlike in iOS, you can put two separate windows from the same app side-by-side if you need to compare two Word documents or Safari windows.

That black line can be clicked and dragged to change how much space each app takes up. The default view is 50/50, but most apps support a 25/75 split (though some, like Calendar, won’t shrink down that far). iOS enforces those strict 50/50 and 25/75 splits, but in OS X the divider can go pretty much anywhere as long as the app supports it. 60/40, 57/43, whatever you want.

From there, work with the apps (and take them out of full screen mode) just as you would have before. This feature isn't exactly necessary in an OS with full support for traditional windowed multitasking, but for people like me who like to use full screen mode to reduce clutter or to ease the pain of working on one small laptop screen instead of a big multi-monitor desktop rig, there's definitely some utility here.

Mission Control and Split View in OS X 10.11. Video by Lee Hutchinson, edited by Jennifer Hahn

This is all a bit easier to learn by watching rather than by reading, so refer to the embedded video above. Other tricks: drag a window to the top of the screen and hold the cursor there for a second to invoke Mission Control (this was unreliable in early betas but is easier and more consistently invoked in the final build). And shake the mouse cursor a couple of times to make it larger and easier to find, a smart tweak if you frequently lose the cursor on those multi-monitor setups.

If there's one thing that makes the new Mission Control a bit less usable than the old one, it's that showing app windows individually instead of by group strips them of the icon and label that told you, in quick and unmistakable terms, what app you were looking at. El Capitan only shows you a text label if you hover the cursor over the window. Also, not all apps that support full screen mode will automatically support Split View, though again this has improved since the early betas. Judging from the documentation, it looks like developers will need to use Auto Layout to take advantage of the feature. If your app's developer isn't on board, the feature becomes less useful.

Spotlight

Spotlight improves in two ways: it expands the number of sources available for the context-sensitive searches introduced in Yosemite, and it responds more intelligently to searches phrased in more natural language. One small, functional improvement is included, too—Spotlight windows can now be resized just like any other window. The Spotlight window will remember its position and size, and you can click and hold the Spotlight magnifying glass in the top-right of the screen to reset it to the default position.

Many of the new sources are things that Siri could already pull in for you in iOS 8 and 9, so they don't exactly feel revolutionary—they really just make one wonder why Siri hasn't put in an appearance in OS X yet, given its ubiquity on every one of Apple's other platforms. You can now use Spotlight to look up the weather, stock prices, and sports scores, rosters, and schedules, all things that you can also use Spotlight or Siri for on your iPhone. It can also pull up video results from Vimeo and YouTube, which will open in the default browser if you click them rather than playing inline.

All of these things add to the list of things you could already look up in Yosemite, including media and apps from the iTunes Store, movie information from Rotten Tomatoes or IMDB, search results from Bing, Wikipedia pages, Maps, and the rest. Disabling these context-sensitive searches and limiting Spotlight to the content stored locally on your Mac can still be done in System Preferences.

Apple also boasts that the new Spotlight can respond to queries made in “natural language,” something that will please anyone who tries to type complete sentences when Googling things (at least if you speak English, Chinese, French, Italian, Japanese, or Spanish). The experience here has improved quite a bit since the early betas. It’s always been pretty good at finding local content, things like “e-mails from Ron” or “pictures from May.” These kinds of searches are now included in the Finder and in Mail (“unread e-mails from last week”) among other places, basically anywhere in the system where the underlying search is powered by Spotlight.

Where it’s improved is in its handling of external content. Spotlight now returns the same results for more stilted, computer-y queries like “Chicago weather” and more human-friendly phrasings like “what’s the weather in Chicago?” The same goes for stock searches, whether you look for them by ticker symbols like “AAPL” or “INTC” or by normal phrases like “Intel’s stock price.” These kinds of searches can also be done from Safari’s address bar, though the Spotlight screen has more room to return more information.

The bad thing about searching for external content, especially if you're just hoping to find stuff on YouTube or something, is that Spotlight still prioritizes local content. You can search for YouTube videos by name, and if Spotlight finds some e-mail from three years ago with similar phrasing it will offer that to you instead of the video. Apple's search features and proactive, Google Now-ish functions are slowly improving, but it's still an area where the software just doesn't feel as "smart" as it needs to be to become part of your standard usage pattern.

App improvements: Notes

Only a handful of applications in El Capitan are picking up big new features, but the humble Notes app gets what is probably the biggest overhaul. The new version lands somewhere in between a heavier note-taking suite like OneNote or Evernote and the Spartan simplicity of the old version. The only functional difference between it and the iOS 9 version is that it can only view sketches—you need an iPhone or iPad to make sketches.

In Yosemite, the Notes app on the Mac could handle some basic rich-text editing stuff, including bulleted lists and bold and italic font styles, and you could paste and drag in links and images. In El Capitan, the app is designed around those slightly richer notes, rather than treating them as edge cases.

Notes picks up a revamped three-column view that can show more stuff than the old one. As before, the first column shows your accounts and folders, the second shows you the notes in those accounts or folders, and the third shows the body text of your note. The first line of your note shows up in the second column as the title, and a preview of the second line shows up as “additional text.”

What little rich text editing that existed in the Notes app before still exists here—you can do bold and italic text and bulleted, dashed, and numbered lists. The real improvement is the way that Notes handles items from other sources.

Open Safari, Photos, Maps, Contacts, or most of Apple’s other first-party apps and you’ll notice that Notes now shows up as an option in the Share sheet. Share something to Notes from those apps, and you’ll be asked if you want to add it to an existing note or create a new one.

That information will then show up in your note, cordoned off in a little box where you can click it to engage with it. A note with any of these little extra boxes embedded in it is said to have an “attachment,” and the number of attachments a note has will show up in the second column along with the title of the note, the last time it was edited, that line of additional text, and an image thumbnail (if applicable). Notes also integrates with the Photos app introduced in OS X 10.10.3—click the Photos button and you can search through your entire library and add images to notes that way, too.

To make looking through all those attachments easier, Notes also picks up an attachments browser that will pull all attachments from all notes and sort them by type (the categories are Photos & Video, Sketches, Map Locations, Websites, Audio, and Documents).

Finally, those of you who already use the Notes app as an impromptu checklist (or appreciate this functionality in apps like OneNote) get some official support from Apple in the form of a "create checklist" button. It functions pretty much the same way as a bulleted list, just with big check boxes to the left of each item; tap the circle to mark (or unmark) the item as "checked." If you’ve got an iPhone or iPad running iOS 9, changes will sync between platforms.

And speaking of syncing, it’s worth noting that these additions all require the use of an iCloud notes account. Notes synced to other accounts just use IMAP, and it’s only capable of syncing simpler, mostly text-based notes. If you’re already using iCloud for your notes, you’ll need to convert them to a new format to use the new features, and you won’t be able to view them on anything that isn’t running El Capitan or iOS 9.

Mail

Mail's new features are smaller and mostly imported from iOS. First, there's swiping. A two-fingered swipe from left-to-right on a compatible multitouch trackpad will reveal a "Mark as Read/Unread" button, and a swipe from right-to-left will expose a "Delete" button. Longer, more decisive swipes in either direction will mark or delete the e-mail without requiring the second click. This is exactly as iOS behaves, though in iOS you also see extra buttons for flagging mail and manipulating it in other ways (not necessary here, since Mail in OS X has room for all those buttons across the top of the window).

Second, the way the Compose window in Full Screen mode works has been tweaked. In Yosemite, composing mail in Full Screen mode would pop up a window that couldn't be dismissed other than to save it as a draft and come back to it later. In El Capitan, the same window can be dismissed to the bottom of the screen by clicking outside it, much as iOS 8 will let you drag the compose window to the bottom of the screen so you can dig through the rest of your inbox. Dragging items (images, other attachments) down to that message at the bottom of the screen will automatically move them to the e-mail you're working on.

Finally, that Compose window picks up a new tabbed view, allowing you to work on several e-mails at once.

Improvements outside of Full Screen mode are smaller and mostly related to the new Spotlight and "Intelligence" features Apple is working into its platforms. Search in Mail now responds to more natural queries like "unread mail from Craig" or "e-mails with attachments from last week." Mail can also pick out meeting suggestions, locations, new contacts, and new information for existing contacts from e-mails and can offer you more detailed information without leaving the Mail window for another app.

OS X will look through your mail and proactively put things it thinks might be appointments into your calendar, and, as in iOS, it will attempt to pick out addresses, flights, and other information proactively in an attempt to be helpful. Unfortunately it seems to be a little picky about what it will and won’t recognize, and it doesn’t pick up as much information as it could. “Let’s meet Sarah in Jake’s office tomorrow at 3:30pm” will trigger a suggested meeting, for example, but it won’t pick up that you’re meeting Sarah or that meeting in Jake’s office. An alternate phrasing like “Meet Sarah in Jake’s office tomorrow at 3:30pm” didn’t trigger an alert either. “1 World Trade Center” is enough of an address to trigger a map preview, but “LaGuardia Airport in New York City” is not. OS X obviously has specific things it’s looking for to activate the feature, and it’s not always obvious just what it needs.

At best, these efforts at proactivity might save you a few seconds in some circumstances. At worst, they won’t work, and you’ll just have to do everything manually as you did before.

Safari and Safari extensions

Safari's biggest new feature is something called "pinned tabs," which allows you to keep specific sites stored on the left of your Safari tab bar at all times. Apple thinks this will be valuable to people who keep a few specific tabs open all day—think things like Twitter, Facebook, or even Reddit.

These pinned sites appear in the tab bar in every Safari window you open. Developers will need to supply a specific kind of image to get a custom icon to appear for pinned tabs. As outlined in Apple’s developer documentation, it needs to be an SVG image with a transparent background that otherwise only uses black. Developers can set one “color” attribute that determines the color the icon takes on when you hover your mouse over it.

One assumes that this particular stipulation is because Apple wants to keep the pinned tab look consistent with the text labels of standard tabs, which could also explain why Safari doesn’t want to display standard favicons like every other browser does. When a site has a properly configured SVG icon, that icon shows up for the pinned tab. If not, Safari just displays a generic icon using the first letter of the site’s name.

If you have one of the pinned sites opened up in one browser window, navigating to the pinned site in another window doesn’t load a new tab—it remembers what you were looking at and shows you that instead. The tab in the first window fades when this is happening and it remembers your scroll position, so Safari is probably just moving the process that runs the tab around rather than opening two processes for the same tab. That by itself could save you some RAM if you're the kind of person who loads five Facebook tabs in each of your Safari windows.

Close all your tabs or quit Safari, and the tab's state will be lost. The tabs also don't auto-load when you open Safari; you have to click them at least once. As long as you stay within the pinned domain, all activity is contained in that tab, but if you click an external link, Safari will open it in a new tab to keep things from getting too confusing.

The next biggest addition is a variation on something Chrome and various extensions and plugins have been doing for a while—letting you locate and shut down tabs that start playing sound without being asked. Apple has added a neat twist, though. When any tab starts playing sound, a small blue speaker icon will appear in the address/search bar. If the sound is playing in the active tab, the default behavior of clicking this is to mute the active tab. If the sound is playing in another tab, the default behavior is to mute it—along with any sound coming from tabs other than the active one. Long-click on the speaker icon and you'll see more options, including one to mute all tabs and a list of all tabs currently playing sound. Click on one of these and you'll hop to the offending tab.

Finally, video embedded in the browser (think YouTube, Vimeo, or others) can now be AirPlayed directly to an Apple TV without needing to broadcast the whole desktop. This is behavior that iOS already supports, but it's nice to see it here.

For developers who want to create extensions for Safari, things are changing a bit. The Safari developer program used to be a free one that ran alongside the for-pay OS X and iOS programs, and anyone could come in and make extensions. Now, developing for Safari requires the $99-per-year unified developer account that Apple introduced back at WWDC.

If you want things to show up in the Safari Extensions Gallery, you need to use the new tools and let Apple sign and host the extension. Once there, the extensions will be able to be updated automatically. Extensions can still be signed with a developer’s own certificate and distributed on other sites, but these can’t be updated automatically. Safari in El Capitan picks up support for iOS 9-style content blockers; methods usable in older Safari versions are still available (for now) but have been deprecated.

Additions by Iljitsch van Beijnum

Safari 9 picks up a Chrome-like Safari status bar. It's useful to have a status bar at the bottom of the window that shows where a link is pointing to, but until now that status bar also took up space when you weren't hovering over a link. Under El Capitan, the status bar auto-hides.

Apple has also made a couple of changes to Safari’s lightweight Reader mode. This is nice and clutter-free, but unfortunately, up until Yosemite, Safari Reader used black letters on a retina-blasting white background in Georgia, a tired-looking serif font. With El Capitan, Reader Mode still looks that way out of the box, but it can now be configured with four color options, ranging from black-on-white to gray-on-black. The font choices are now Athelas, Charter, Georgia, Iowan, Palatino, Times New Roman (serif fonts), San Francisco, and Seravek (sans serif). Just in case you have trouble finding it: the Reader configuration option appears on the right on the URL bar (where you would normally find the stop/reload button) when you enable Reader mode.

Maps

I think this one deserves a “finally”—Apple Maps finally supports public transit directions and routing, and we’re getting our first taste of it on OS X. If you don’t ride trains or buses you won’t care, but this is important for city dwellers or visitors.

Ever since Apple switched to its own mapping data in iOS 6, users of the bundled app have had to get by without directions for public transit. They could either download one of the suggested third-party transit apps for their location (hit-and-miss, both visually and functionally) or just replace Maps outright with an alternative like Google Maps (which is what I do).

Note that my experience with Maps is exclusively focused on the Jersey City and New York City areas, which are covered. Other US cities include San Francisco, Washington DC, Philadelphia, Chicago, and Baltimore (sorry every other city!).

Apple’s implementation, belated and limited as it is, seems well done and attractive. The new Transit view shows you the multicolored spiderweb of train lines with small dots for each station, and you can click those stations to see which lines run through them and when those trains run. Getting transit directions works pretty much the same way as it does in Google Maps. Maps gives you the nearest train and the time, along with the number and (if you expand) names of all the stops in between and walking directions to the departure station and away from the destination station.

And that’s where you get to the one place where Apple really trumps Google, at least until Google adds this feature to its own mapping software. Apple has noted the number and location of every station entrance and exit, as well as the shape of the station itself.

If you use a station often enough, you eventually figure out the best entrance and exit points yourself, but this will be really useful for both tourists and transplants. Some of these stations span multiple city blocks, and you don’t want to leave only to find out that you should have gone out the opposite way. These directions should also help me fix a problem I still have after two years of living here, the old walk-half-a-block-before-you’ve-realized-you’re-going-the-wrong-way conundrum.

Maps is more useful in iOS 9 than in OS X just by virtue of being more mobile. But OS X’s Maps app has the benefit of being able to send routes directly to your phone, and if you’ve got a Mac and an iPhone and an Apple Watch, and you want to use its turn-by-turn navigation, you’ll need to use Maps anyway. It’s a good example of how sticky Apple’s ecosystem is becoming—every hardware purchase pulls you just a little deeper into Apple’s software and services. There are still plenty of places, in iOS especially, where third-party apps can exist but offer an inferior experience, and they don’t offer the same cross-device compatibility as Apple’s apps and services do.

Photos

Photos is a replacement for both iPhoto and Aperture, but it really only replaces the latter insofar as Apple stopped supporting Aperture when Photos came out. Photos’ feature set should generally be satisfactory for iPhoto users, but it’s far less capable than Aperture was.

That’s not changing in El Capitan, exactly, but Apple is opening the door for developers to step in and fill some of those feature gaps. Photos will now accept third-party editing extensions, which should integrate seamlessly into the UI and show up right alongside the editing tools that are already there. We’d like to see Apple create a couple of its own Aperture-level extensions to point the way forward for developers, but even without those, this is Photos’ best chance to woo current Aperture users away from competing products like Adobe’s Lightroom.

Photos is a pretty young app, so most other changes are fairly minor: it’s possible to add locations to individual photos and to moments, you get some new album sort options, and Apple says it has improved performance and stability for users with large photo libraries.

Disk Utility

The GUI version of Disk Utility hasn’t gotten a substantial facelift (other than to pick up new button and icon styles) since OS X 10.3, when the disparate Disk Utility and Disk Copy tools were merged into one. El Capitan delivers a new version that gives you more information about your disk, things you would usually need to go to About This Mac or System Information or the diskutil command line tool to see.

In the left column of the window, you’ll still see a hierarchical view of all of your physical disks and logical volumes, but the view to the right is different. For physical disks, you’ll see a color-coded map of the partitions on the disk. For logical volumes, that same color-coded bar shows you how much of the drive’s space is taken up with applications, images, audio, movies, and “other,” as well as free space.

Below that you’ll see the somewhat more detailed view that the old Disk Utility would have given you—total partition size and used space, the available space, and the identifier. You’ll also see the physical connection the drive is using (that will be SATA for older Macs, PCI-Express for newer ones).

Hit “info” to see still more detailed information, including filesystem and CoreStorage UUIDs, whether the drive is bootable or encrypted, or whether the System Integrity Protection feature is enabled for the volume.

The other buttons encompass most of Disk Utility's old functionality. You can partition drives, format, unlock encrypted disks, and mount and unmount volumes. Other options like creating, verifying, and restoring disk images are still available in the menus. A single "First Aid" button replaces the old buttons to verify and fix your disk and its permissions—it verifies the disk, but manual permission repair has been relegated to the command line tool. Apple says that permission protection and repair (long considered a broadly pointless placebo of a troubleshooting step in the first place) now occurs automatically during software updates.

Other things are gone from the GUI version, though the list has shrunk since the early betas. Disk images like ISOs and DMGs can be opened in Disk Utility, but any and all references to burning images to disk have been removed even on Macs that still have optical drives. This includes the Command-B keyboard shortcut. To burn an image to CD or DVD, you’ll either need to use the command line version of the utility or the Finder. One could argue that disc burning is a "legacy" feature, but it’s still useful for the many, many older Macs that El Capitan supports.

Multi-pass formatting security options also seem to have reappeared for spinning hard drives and external media that need them, though not for internal SSDs. Apple's support document claims its SSDs don't need a secure erase feature, but, to be sure, you could always encrypt the disk and then wipe it from the recovery partition or a USB install drive.

The command line diskutil tool appears to be unchanged, so any scripts or workflows you have that use it should continue to work as they have. You can still use it to access secure erase functions and other things stripped from the GUI.

Metal

Metal is another feature imported from iOS, a graphics and GPU compute API designed to eliminate some of the overhead of OpenGL and OpenCL. Metal's primary function is to move some of the processing load from the CPU to the GPU to alleviate bottlenecks, particularly those related to draw calls. This can simultaneously speed up graphics while also leaving the CPU free to handle physics calculations, AI, or other things the GPU can't do.

Apple's sales pitch for Metal leans primarily on the gaming use case, outlined above, and for professional apps that use 3D rendering or GPU compute. At WWDC, Apple boasted of an 8x rendering performance improvement in Adobe After Effects and products from companies like Adobe, The Foundry, and Autodesk. Apple's own apps—Final Cut Pro and the like—are more than likely to pick up Metal support, too.

Aside from heavy 3D applications, Apple has also integrated Metal support into Core Graphics and Core Animation—these are responsible for 2D rendering and most of the animation that happens on the OS X desktop.

Since our first preview of El Capitan, we’ve learned more about the Metal hardware requirements and exactly what parts of the API are supported on what devices. Our initial guesses weren’t too far off. Macs introduced in or after 2012 all support the Metal API, including:

MacBook (Early 2015)
MacBook Pro (2012 or newer)
MacBook Air (2012 or newer)
Mac Mini (2012 or newer)
iMac (2012 or newer)
Mac Pro (Late 2013)

Intel doesn’t support APIs like DirectX 12 and Vulkan on Ivy Bridge’s older HD 4000 GPU, so we’re pleasantly surprised to see Apple extend Metal support to that slightly older chip. Other than that, there aren’t big surprises, though it’s possible that Apple could have been more aggressive about supporting some older dedicated GPUs.

Even if your Mac is on the support list, there’s a chance that it doesn’t use all of Metal’s advertised features. For example, Apple tells us that the Core Graphics and Core Animation acceleration is available only on Macs that use Intel integrated graphics exclusively. It’s not available on higher-end Macs with dedicated GPUs or in laptops that switch dynamically between integrated and dedicated graphics. The Intel GPUs are the ones that need the most help driving OS X’s UI, but it still seems a bit odd. That said, all of the Macs on the support list can use Metal for gaming and GPGPU tasks, integrated or dedicated.

What we’re hoping is that Metal will help with fluidity and responsiveness on 4K and 5K displays and on Retina screens, especially when they’re being used at scaled, non-native resolutions. The way OS X handles scaling (making a screen that looks like a 1280×800 display look like a 1440×900 display instead) is cleaner for users and developers than the system Windows uses, but it’s harder on your GPU, which is asked to draw resolutions far beyond your display panel’s native resolution. Especially if you have multiple high-resolution displays connected to your Mac or if you’re using a system with a relatively underpowered GPU like the Retina MacBook, this can lead to choppy and inconsistent performance.

And it’s hard to tell if this is because of Metal or because of other changes Apple has made to OS X, but animations and fluidity on the Retina and 4K Macs we’ve tested do seem substantially improved in El Capitan relative to Yosemite. Opening a dozen app windows and then using Mission Control in “looks like 1440×900” mode on the 2015 MacBook was a sure way to see some stuttering in Yosemite, but in El Capitan it’s smooth sailing. The same thing applied to a 2015 15-inch Retina MacBook Pro with Intel’s Iris 5200 GPU, even when connected to an external 60Hz 4K display and with scaling turned all the way up.

We say it’s hard to attribute this to Metal because the Mission Control animation looks less strenuous in El Capitan than in Yosemite, though. In Yosemite the background turns translucent and brings up thumbnails for your different Spaces instantly. El Capitan doesn’t do anything to your desktop background and only loads those thumbnails on request. In any case, things ought to get better, especially on newer Macs.

We’re working on getting some benchmarks for Metal so we can compare its performance against OpenGL on a variety of different Macs, but the tools we need aren’t available just yet—we’ll either update this review or run a separate piece when we can get the software.

OpenGL: Still lagging behind

Metal is great and all, but Apple’s focus on its new graphics API appears to be coming at the expense of OpenGL. According to the OpenGL Extensions Viewer, El Capitan supports the same OpenGL level that Yosemite and Mavericks did: full support for OpenGL 4.1, with a couple of 4.2 extensions thrown in.

To put this in perspective, the OpenGL 4.1 spec was finalized back in 2010, and versions 4.2, 4.3, 4.4, and 4.5 followed in 2011, 2012, 2013, and 2014, respectively. On Windows and Linux, modern GPUs from Intel, AMD, and Nvidia all support at least version 4.3 or 4.4, so Apple is behind here by quite a bit.

Apple still supports OpenGL on OS X, insofar as it’s not removing OpenGL capabilities that are already there. But it’s clearly moving forward with Metal on its platforms as a replacement for both OpenGL and OpenCL going forward. It’s worth noting that iOS also stopped keeping up with new OpenGL ES extensions in iOS 8 when Metal debuted, though Metal performance improved a bit in the move to iOS 9.

We’ve asked Apple about future OpenGL plans but haven’t received a concrete response. We wouldn’t count on additional OpenGL or Vulkan support anytime soon, though. It’s not the worst thing in the world for Apple to maintain its own graphics and GPGPU API (look at DirectX), but it’s a step back from the kinds of open standards that the company used to champion more aggressively.

System Integrity Protection

The BSD underpinnings of OS X have led to Apple using POSIX security as one of the "moats" surrounding the proverbial security castle. Briefly, this means that OS X uses a BSD/Unix-like file system layout and permission structure. Central to this is the concept of "root," an all-powerful account with effectively limitless access to the file system. The root account on a Unix-like system can have many names, but it always has the user ID (UID) of "0," and the account with UID 0 is granted special privileges by the operating system kernel. The operating system uses the root account, for example, as the context under which privileged processes or applications are launched.

Screenshot of htop on an Ubuntu server, showing processes running under many contexts. The nginx master process, for example, was started as root (it needs to be able to do root-y things, like read the Web server's SSL/TLS private key), and then spawned a number of unprivileged worker processes.

OS X has always had a root account with a UID of 0, and it’s still there in El Cap:

The root user in El Capitan—still present, still UID0.

Mac users who have gone exploring in the bowels of the operating system—or who have needed to do some command line trickery to solve weird problems—have probably run into situations where they needed to use root-level privileges in one way or another. It’s pretty rare that you actually have to log on interactively as root (and the root account itself is disabled by default on OS X), and usually it’s far more convenient to temporarily give your account root privileges as needed. By default, this kind of "privilege escalation" is available to any local accounts on your Mac that are classified as administrators. You most often run into such a request for escalation when your Mac pops up a dialog box asking for your password when you’re installing new software or trying to delete something out of the Applications directory. Command line fans can also execute commands with root privilege by prefacing them with the sudo command, which stands for "super user do."

Root—or an account operating with root privilege—can do just about anything. That can be equal parts useful and dangerous. The root account's effectively unlimited ability to execute commands means that an attacker with root privilege can do just about anything to a computer. El Capitan’s "System Integrity Protection" feature is an attempt to limit the damage an attacker can do by limiting what root itself can do.

OS X's "defense in depth" security model, showing the different layers of the operating system's security stacked like a fortress with moats and bridges and walls. SIP is an enhancement to the "POSIX" layer.

System Integrity Protection does this by severing the automatic kernel-level blessing given to root’s commands. The end result is that in El Cap, root is no longer an account with effectively unlimited access to either the file system or to memory and running processes. SIP places kernel-level checks on root’s privilege that can (in theory, at least, until proven otherwise by an intrepid security researcher) only be bypassed by the kernel itself. SIP’s intention is to keep the operating system’s state—both on disk and in memory at runtime—as it was installed by Apple.

This is a pretty big change from how Unix-like operating systems are "supposed" to work, though it’s not without precedent (Ars IT Editor Sean Gallagher told us that SIP sounds a bit like Trusted Solaris, and this Quora thread has some details on the history of similar "rootless" privilege escalation schemes). Rather than adding yet another superuser account, SIP provides the concept of an additional file system and process flag, and file system objects and in-memory processes so flagged cannot be altered by processes not signed with Apple’s own code signing key.

There’s more, too—the file system protections are only the start. SIP consists of four major features:

Protected locations cannot be written to by root.
Protected system processes cannot be attached to with a debugger and cannot be subject to code injection.
All kernel extensions must now be signed (and old methods for disabling kernel extension signing are gone).
SIP cannot be disabled from within the operating system, only from the OS X Recovery partition.

Each of these four points has a bunch of different caveats. But first, let’s get two obvious questions out of the way: yes, you can disable SIP if you want to—you have to boot into the OS X Recovery partition to do so, but it’s not difficult.

But should you disable SIP? For something like 95 percent of El Cap users, the answer is an emphatic no. There are almost no downsides to SIP for most users. Developers will probably want to toggle it off on their development computers if they’re building complex applications, but most folks should just leave it alone—even the "power users" among us who like to tweak and fiddle.

File- and block-level protections

The file and directory protections are the part of SIP that users are most likely to actually encounter. To start with, SIP drops an impenetrable curtain around the following four locations:

/System
/bin
/usr
/sbin

Any attempts to write to those locations will be denied, even when using escalated privilege:

Trying to create a file in the System directory, which is a SIP location.

SIP prevents more than just writes, too. On a system with SIP active, you can't even mount other devices over SIP-protected paths, thus shutting off a potential way to do malicious (or at least creative!) things:

When upgrading from previous versions of OS X to El Cap, any and all non-Apple files found to be residing in those directories will be picked up and moved to /Library/SystemMigration/History/Migration-(some UUID)/QuarantineRoot/—which will almost certainly render whatever application or piece of hardware that depended on those files nonfunctional.

(Correction: We originally listed /Library/PreviousSystems as the SIP third-party migration target, since that location was the one given in Apple's prerelease developer documentation for SIP, but this is incorrect. The correct location, complete with a randomly-assigned UUID, is now shown above.)

SIP file relocation from protected areas during upgrade isn't a remote eventuality, either. Some developers are careless with where they place files, particularly when it comes to third-party drivers. It’s conceivable that if you’ve got a crufty OS X install with a lot of third-party hardware hanging off your Mac, this particular aspect of SIP is going to affect your upgrade to El Cap. More than one Ars author has been bitten by third-party drivers being relocated during the upgrade.

Instead of allowing developers to put files wherever they want, El Cap offers four canonical safe locations for applications, support files, and drivers:

/Library
~/Library
/usr/local
/Applications

The local or system library directories are the preferred stand-in for /System, and /usr/local is the preferred stand-in for /usr, /bin , and /sbin. However, Apple strongly recommends that developers use /Applications for everything if possible, since that keeps all of an app’s files in a single location for ease of uninstallation.

At least for now, SIP only applies to the root/boot volumes of the current operating system installation—so, for example, adding a second OS X installation on your Mac and booting into it would give you the ability to make whatever file-level changes you want to the first OS X installation. This sounds like a significant security oversight, but the obvious response to that criticism is that if a potential attacker has enough access to your Mac to be able to install a second operating system on it, you’ve got problems a lot bigger than SIP can help you with.

Even though SIP only applies to the root and boot volumes, it is a persistent, system-wide feature. So if you have two El Cap installs on one Mac, for example, whichever one you boot into will have SIP active if SIP is enabled. To accomplish this cross-OS persistence, SIP’s settings are kept not on the storage volume itself but rather in NVRAM, so they remain in force between reboots and even between disk swaps.

Digging in a little deeper at the file level

For a bit more info on what SIP does, we need to take to the command line. Apple’s developer documentation mentions that SIP file system locations are protected with a particular attribute, so let’s pick up our old friend xattr to show the protected directories’ extended attributes:

raptor:~ lee$ xattr -l /System
com.apple.rootless: 

raptor:~ lee$ xattr -l /bin
com.apple.FinderInfo:
00000000  00 00 00 00 00 00 00 00 40 00 00 00 00 00 00 00  |........@.......|
00000010  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  |................|
00000020
com.apple.rootless: 

raptor:~ lee$ xattr -l /sbin
com.apple.FinderInfo:
00000000  00 00 00 00 00 00 00 00 40 00 00 00 00 00 00 00  |........@.......|
00000010  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  |................|
00000020
com.apple.rootless: 

raptor:~ lee$ xattr -l /usr
com.apple.FinderInfo:
00000000  00 00 00 00 00 00 00 00 40 00 00 00 00 00 00 00  |........@.......|
00000010  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  |................|
00000020
com.apple.rootless: 

raptor:~ lee$ xattr -l /usr/local

raptor:~ lee$

On each location, we've got a com.apple.FinderInfo attribute and a com.apple.rootless attribute. By way of comparison, the last location, /usr/local, is unprotected and has no extended attributes.

The com.apple.FinderInfo attribute was touched on a couple of years ago in our OS X Mavericks review:

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

The FinderInfo flags shown on /bin, /sbin, and /usr don’t have anything to do with SIP—instead, they mark the folders as hidden folders. You can actually set that on objects yourself if you’d like:

raptor:~ lee$ mkdir mydir

raptor:~ lee$ chflags hidden mydir

raptor:~ lee$ xattr -l mydir
com.apple.FinderInfo:
00000000  00 00 00 00 00 00 00 00 40 00 00 00 00 00 00 00  |........@.......|
00000010  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  |................|
00000020

This is also why /System doesn’t have that particular extended attribute—unlike the others, /System isn’t a hidden directory.

The thing that we do care about is that com.apple.rootless attribute. That’s the SIP attribute, marking the directory and its child object as protected. It works, too—on Yosemite and earlier, we can toggle these directories’ hidden flags to off, but trying to do so in El Cap results in the same "Operation not permitted" error as you get when trying to do any writes to a protected location:

raptor:~ lee$ sudo chflags nohidden /usr
chflags: /usr: Operation not permitted

raptor:~ lee$ sudo xattr -d com.apple.FinderInfo /usr
xattr: [Errno 1] Operation not permitted: '/usr'

The list of file system objects granted to the com.apple.rootless attribute—along with those specifically exempted from it—is found at /System/Library/Sandbox/rootless.conf. As expected, the list contains the four prime protected SIP locations. However, it also contains a whole slew of additional SIP objects, including a bunch of core OS X applications:

raptor:~ lee$ cat /System/Library/Sandbox/rootless.conf 
				/Applications/App Store.app
				/Applications/Automator.app
				/Applications/Calculator.app
				/Applications/Calendar.app
				/Applications/Chess.app
				/Applications/Contacts.app
				/Applications/Dashboard.app
				/Applications/Dictionary.app
				/Applications/DVD Player.app
				/Applications/FaceTime.app
				/Applications/Font Book.app
				/Applications/Game Center.app
				/Applications/Image Capture.app
				/Applications/Launchpad.app
				/Applications/Mail.app
				/Applications/Maps.app
				/Applications/Messages.app
				/Applications/Mission Control.app
				/Applications/Notes.app
				/Applications/Photo Booth.app
				/Applications/Photos.app
				/Applications/Preview.app
				/Applications/QuickTime Player.app
				/Applications/Reminders.app
				/Applications/Safari.app
				/Applications/Stickies.app
				/Applications/System Preferences.app
				/Applications/TextEdit.app
				/Applications/Time Machine.app
				/Applications/Utilities/Activity Monitor.app
				/Applications/Utilities/AirPort Utility.app
				/Applications/Utilities/Audio MIDI Setup.app
				/Applications/Utilities/Bluetooth File Exchange.app
				/Applications/Utilities/Boot Camp Assistant.app
				/Applications/Utilities/ColorSync Utility.app
				/Applications/Utilities/Console.app
				/Applications/Utilities/Digital Color Meter.app
				/Applications/Utilities/Disk Utility.app
				/Applications/Utilities/Feedback Assistant.app
				/Applications/Utilities/Grab.app
				/Applications/Utilities/Grapher.app
				/Applications/Utilities/Keychain Access.app
				/Applications/Utilities/Migration Assistant.app
				/Applications/Utilities/Script Editor.app
				/Applications/Utilities/System Information.app
				/Applications/Utilities/Terminal.app
				/Applications/Utilities/VoiceOver Utility.app
				/Library/Preferences/SystemConfiguration/com.apple.Boot.plist
				/System
*				/System/Library/Caches
booter				/System/Library/CoreServices
*				/System/Library/CoreServices/Photo Library Migration Utility.app
				/System/Library/CoreServices/RawCamera.bundle
*				/System/Library/Extensions
				/System/Library/Extensions/*
UpdateSettings			/System/Library/LaunchDaemons/com.apple.UpdateSettings.plist
*				/System/Library/Speech
*				/System/Library/User Template
				/bin
dyld				/private/var/db/dyld
				/sbin
				/usr
*				/usr/libexec/cups
*				/usr/local
*				/usr/share/man
# symlinks
				/etc
				/tmp
				/var

The list is organized in columns, with the leftmost containing an account or group that is allowed to write to the location. Entries with nothing in the first column are wholly protected by SIP. Entries prefaced with an asterisk (the wildcard character), on the other hand, allow writes by any account (look, for instance, at /usr/local—the asterisk in front of it means anyone can write to it). The list is effectively an additive permission list, and subdirectories inherit their parent directories’ SIP protection—for example, /usr/local has to be specifically excepted because its parent, /usr, is listed. You can add things to /System/Library/Extensions, but you can’t change anything there, because /System/Library/Extensions/* is listed. Unlisted locations aren't watched by SIP—and, yes, SIP also protects the rootless.conf file from being modified. That was the first thing we tried.

The inclusion of OS X default applications in the list means that they inherit the same file system protections as any other SIP location—if you want to delete Mail.app because you only use your third-party mail application, you’re out of luck. Even the usually reliable nuclear option of sudo rm -rf is rendered toothless. We were able to reboot into a parallel Yosemite installation and delete SIP-protected things from the El Cap partition. Upon reboot to El Cap, the system didn't appear to be upset that Chess.app was missing.

Deleting a SIP-monitored application from a Yosemite install. Breakin' the law, breakin' the law.

We haven’t touched much direct block-level writes to the system volume, since that’s normally kind of a difficult thing to do, but it’s also covered by SIP. Block-level writes to any volume that hosts SIP-protected content are automatically blocked. To test this, we pulled down the nifty little iBored utility by Thomas Tempelmann, which can be used to do all kinds of things that you should never actually try to do—like manually edit your MBR (those of you who like me are old enough to remember the suicidal days of hex-editing our MBRs in DOS with the Norton Utilities are probably frantically waving your hands right now). On a Yosemite Mac, I was able to toggle on the ability to perform direct block writes in iBored with a simple root escalation:

The "W" in the last column indicates that the volume has been unlocked for direct block writing. This is my everyday computer and taking this screenshot made me scared.

On El Cap, trying to do the same escalation fails with a sandbox error:

SIP prevents this potentially suicidal behavior.

Running protections

SIP protects the integrity of the file system, but all the file system protection in the world isn’t worth a lot if a malicious actor can poke through RAM, injecting code into active processes and changing the behavior of programs as they run. This scenario is also covered by SIP’s runtime protections—in fact, in many ways, the runtime protections are even more restrictive than the file system protections.

SIP runtime protection applies to any application with the SIP flag—so, all the Apple applications listed in /System/Library/Sandbox/rootless.conf—and also to any application signed with an Apple private entitlement key. This means that Apple could introduce new SIP-protected applications not listed in rootless.conf and they’d still keep the same protection.

Any application thus flagged gains kernel-enforced protection and cannot be attached to with a debugger, and that protection (again, at least until firmly shaken by a security researcher) appears inviolable from within the operating system. Attempting to fork a privileged binary will result in an error. Attempting to inject code into Finder will result in an error. Attempting to inject libraries into system binaries will result in an error. Even trying to poke into a protected process with DTRACE will fail—probes that try to target protected processes will fail to match, and no interaction with the kernel will be visible, and protected memory space will be simply inaccessible. Not even LLDB will be useful. You won’t be able to invoke it on system processes, regardless of root privilege.

Going hand-in-hand with the runtime protection is mandatory signing for kernel extensions. As of El Cap, the methods for working around KEXT signing (like using sudo nvram boot-args='kext-dev-mode=1') have been removed, and KEXT signing enforcement is now under SIP control. El Cap will refuse to load any kernel extensions that aren’t signed by a valid Apple developer ID.

OS X users who depend upon unsigned KEXTs for extra functionality—be it third-party hardware with unsigned drivers or software like OSXFuse that depends upon unsigned kernel extensions—will have precisely two alternatives: stop using the applications or hardware until the developers provide signed KEXTs, or disable SIP altogether.

Developers, developers… developers?

These changes obviously have wide and far-reaching implications for OS X developers. On one hand, anyone who’s had their proverbial ear to the ground should have heard at least some of this coming. The push toward ensuring that applications behave "correctly" and that rogue or compromised applications cannot cause tremendous system-wide damage is being dramatically accelerated with SIP.

On the other hand, it also severely complicates the landscape for developers who want to construct extremely complex applications with deep system integration. It’s easy enough to load up Xcode and bang out a quick Swift-based TextEdit.app clone, but what if you’re up to your elbows in C++ trying to create a Final Cut Pro X competitor or something else that needs deep system access at runtime? Disabling SIP is certainly a good step for a developer to take on their dev box—and we’ll get into that in just a moment—but it seems like there are now significant barriers toward developing big apps.

These barriers may not be a problem if you’re sufficiently large—Microsoft and Adobe, for example, have the ability to work directly with Apple for developing OS X versions of Office and Premiere—but SIP’s additions to OS X sandboxing mean that smaller developers now have a lot more rules to follow.

Disabling it all

If you’re of a mind to disable SIP—and, truthfully, we don’t recommend doing so unless you have a legitimate need—you can do it by booting into the OS X Recovery partition. Restart your Mac and hold command-R at boot to perform a Recovery partition boot, and then open up a Terminal window. Early preview versions of El Cap came with a GUI "Security Configuration" utility used to disable SIP, but in the final build it looks like you'll have to resort to the command line. The csrutil utility is used to check SIP's status and toggle it on and off. Interestingly, csrutil also has an option for adding secure network boot locations—which makes sense, given the ability to manipulate SIP's NVRAM settings this way.

Trimforce and third-party SSDs

After years of ignoring them, Apple added support for TRIM with third-party SSDs early in the summer with OS X 10.10.4. Prior to this, OS X only supported TRIM on Apple’s own OEM SSDs (which were often built by Samsung, though the company also sources drives from Toshiba and SanDisk), and you needed an unsupported third-party tool like TRIM Enabler to turn it on for other drives. The lack of TRIM support on all but Apple-branded SSDs was a sore spot for Mac users looking to add SSDs to Macs that originally rolled off the factory floor equipped with hard disks or to users trading their factory SSDs for aftermarket drives with higher speeds or capacities, but the official tool came with its own scary-sounding caveats.

As a very quick refresher, TRIM is an ATA command that operating systems can cause to be issued to SSDs when files are deleted; it tells the SSD that the blocks mapped to the deleted file can be marked as stale and cleaned for reuse during the next round of SSD garbage collection. Without TRIM, the SSD has no way of knowing when the operating system deletes files, and the operating system has no way of telling the SSD (because typically, a "deletion" in a modern file system is actually just a quick write, not an actual-for-real zeroing-out of the deleted data). TRIM isn’t a mandatory thing, but it’s definitely nice to have.

If you’d like more of a refresher on TRIM, you can check out our piece from April on whether or not TRIM is something you should care about. If you’d like a whole deep-dive on not just TRIM but SSDs themselves, including a discussion of where TRIM fits into the processes by which SSDs keep themselves clean and operational, you can hit up our big SSD explainer.

One of the Macs we loaded El Cap on was an old 2007 Core 2 Duo iMac that had been upgraded with an SSD, and we enabled third-party TRIM on it with the trimforce command (introduced as a Yosemite feature in June 2015). We wanted to see if we could verify that TRIM was actively working on third-party SSDs in El Cap. This turned out to be a bit tricky to actively check, since it requires peeking under the hood into the file system—but this is Ars Technica, damn it, and this kind of stuff is what we do.

TRIM (written capitalized not because it’s an acronym, but because it’s a command from the AT Attachment command set) is a hard thing to catch in action. Usually, if it’s working, you don’t really notice it at all—it simply helps the SSD keep its pool of spare pages as large as possible. To actually verify that it’s functioning, you need to be able to check on the contents of a file system logical block. In a Linux distro with an EXT4 file system and the right kernel, you can use the hdparm command to sleuth its workings out, but unfortunately hdparm isn’t available on OS X even via Homebrew or Macports.

Thomas Tempelmann’s iBored utility again came to the rescue. Using it, we were able to peek at logical block contents and catch TRIM doing its thing.

To set a baseline, we checked to see if TRIM was observable on a MacBook Air with an SSD from Apple. To do this, we needed to create a file to figure out what logical blocks correspond to that file, check them for data, delete the file, flush the disk’s queue to make sure it executes any pending TRIM operations, and then check the (former) file’s blocks again to see if they’re empty.

But before we created the file, we needed a way to observe the file being written, so we used fs_usage. Because fs_usage will tell you lots and lots of things—far more than you usually want to know—we constrained its output to only file system activity with a flag:

$ sudo fs_usage -f diskio

With fs_usage happily babbling away in one window, we pulled up a second terminal window and, using dd, created a ~50 megabyte file full of random gobbledygook:

raptor:~ lee$ dd if=/dev/urandom of=tempfile4 count=100 bs=512k
100+0 records in
100+0 records out
52428800 bytes transferred in 5.597703 secs (9366128 bytes/sec)

Once the file was created, we stopped fs_usage and took a look at its output. There was a bunch, but the lines we were concerned about were the ones showing writes to the disk by the dd tool, like this:

18:00:35.610738    WrData[A]       D=0x00fc5198  B=0x80000  /dev/disk1  /Users/lee/tempfile                                      0.005044 W dd.13737
18:00:35.721541    WrData[A]       D=0x00fc5598  B=0x100000 /dev/disk1  /Users/lee/tempfile                                      0.005127 W dd.13737
18:00:35.845888    WrData[A]       D=0x00fc5d98  B=0x100000 /dev/disk1  /Users/lee/tempfile                                      0.005176 W dd.13737
18:00:35.959810    WrData[A]       D=0x00fc6598  B=0x100000 /dev/disk1  /Users/lee/tempfile                                      0.005104 W dd.13737

…and so on. The D=0x... entries are the actual logical blocks being written to. We picked one block—it ended up being 0x00faee90—and put the block’s address into iBored’s block viewer to see its contents:

As expected, the block contained essentially random data courtesy of dd. Next, we dragged the file to the trash, emptied the trash, and issued the sync command to force the operating system to complete any pending writes. Then we checked the contents of block 0x00faee90 again, and, as expected, it displayed all zeros, indicating that the TRIM command had done its job and the SSD had erased the physical disk block containing the page that corresponded to the logical block we were tracking.

Sound a bit confusing? It is. There are multiple layers of abstraction between where the operating system thinks a file is and where the file really is. Our big SSD explainer is the place to go if you need the whole structure explained.

Now, what we’d expect if TRIM were working on third-party SSDs would be for the same procedure to yield the same result on a Mac equipped with a third-party SSD. And, fortunately, that's just what happened.

Our aluminum Core 2 Duo iMac is equipped with a 256GB Crucial M4 SSD with the latest firmware installed. First, we walked through the entire procedure without TRIM enabled, to see what kind of behavior we would observe. As expected, after deleting the file and flushing the queue, the logical block remained filled with data—because, of course, without TRIM the operating system has no way to tell the SSD what pages to garbage collect. Then we enabled TRIM with trimforce and repeated the whole procedure. With no fuss, the block showed all zeroes after the test file was deleted.

The solid conclusions that can be drawn from this are somewhat limited, but we can say with reasonable certainty that if your third-party SSD properly implements TRIM, then El Capitan will take advantage of it when told to do so with trimforce. Further testing is warranted as SSDs continue to evolve, but for now, Apple’s approach to it is much like the company’s general approach to third-party hardware—it works, or it doesn’t work, and Apple has nothing to say about it on third-party disks other than that you pays your money and you takes your chances.

This approach makes sense from Apple's perspective. It’s already very difficult to buy a Mac without solid state storage, and working TRIM support isn’t an issue for SSDs you do get from Apple. The edge cases right now are older non-SSD Macs with third-party SSDs being added by users as upgrades. Given the longevity of Macs and the plethora of SSDs, some number of users definitely will want to add non-Apple SSDs on to Macs as they age, and while trimforce automates the process, it's not guaranteed to work. You probably won’t lose anything by turning it on, unless your SSD’s controller has bugs in its TRIM implementation, in which case you might lose a lot.

Networking: mDNSResponder

Networking sections authored by Iljitsch van Beijnum

A year ago, Yosemite added Handoff and Continuity and made AirDrop work between Macs and iOS devices. Apple emptied its entire bag of networking tricks to make these features work: iMessage, iCloud, Bluetooth Low Energy, Wi-Fi, Bonjour. At the same time, some of Apple's famed autodiscovery of networked services took a huge hit in reliability. Connecting to another computer on the local network or having a computer running iTunes wake up when an Apple TV wants to play back content had been solved problems for the better part of a decade, but these actions no longer worked reliably in Yosemite.

Turns out, the mDNSResponder daemon that is in charge of discovering services running on other systems connected to the local network (and responsible for handling DNS requests required to connect to the Internet) was replaced with a new discoveryd daemon. Naturally, replacing code that has been refined over a decade with something completely new would introduce some bugs, but the number and severity of the issues caused by the change was surprising to say the least. It's particularly strange considering that discoveryd doesn't actually power any of the new Continuity features, as we learned when we replaced discoveryd with the old OS X 10.9 mDNSResponder. This made all of the new issues disappear while Continuity continued to work. A few months later, in true Steve Jobs-ian fashion, the daemon that founded Bonjour network service discovery and then got kicked out was brought back to turn the sinking ship around.

Word on the street is that going back to mDNSResponder allowed Apple to close 300 separate bug reports. And apparently the company wasn't looking to reopen those reports, as OS X 10.11 comes with mDNSResponder version 624.1.2 . The final 10.9 version of the daemon was 522.92.1 and 10.10.5 comes with version 576.30.4.

Happy eyeballs look toward IPv6

Now that regular IPv4 addresses are hard to come by in most parts of the world, more and more Macs find themselves connected to IPv6-capable networks. OS X has supported the new version of the Internet Protocol since 10.2 Jaguar, and it's added various refinements over the years. Originally, if a Mac had both IPv4 and IPv6 connectivity and wanted to connect to a server that also has IPv4 and IPv6, the system would prefer to use IPv6. However, back in the big cat era, IPv6 was often still experimental and not as reliable as IPv4. To avoid lengthy network timeouts when IPv6 seemed to be present but didn't actually work, Apple added a mechanism known as "happy eyeballs.” This feature tries to make the Web browsing experience “happier” by having the system try to connect over both IPv4 and IPv6, settling on the IP version that is fastest and abandoning the slower connection.

Under Yosemite, the result was that Safari and other applications using the higher-level network APIs would use IPv4 and IPv6 each 50 percent of the time if both types of connectivity are of equal quality, but on systems where IPv6 packets take a slightly longer path, IPv4 would be used most of the time. That was appropriate when IPv6 was still experimental, but these days, IPv6 performance and stability is as good as that of IPv4, if not better. IPv4 traffic typically needs to pass through a Network Address Translator (NAT), which may or may not be a bottleneck, but a simple round-trip time measurement won't reliably detect this. Accordingly, Apple has decided to change its happy eyeballs algorithm.

When an iOS 9 or OS X 10.11 application running on a system that has both IPv4 and IPv6 wants to connect to a server, it asks the DNS for the IPv6 and IPv4 addresses of that server, with the two requests going out back-to-back. If the first answer that comes back is the one for the IPv6 addresses, an IPv6 connection is set up immediately. If the first answer that comes back is the IPv4 answer, the system waits 25 milliseconds for the IPv6 answer to come in. If that doesn't happen in 25 milliseconds, it connects over IPv4. When the IPv4 answer arrives first and the IPv6 answer arrives within 25 milliseconds, or when both the IPv4 and IPv6 addresses of the remote server were already cached, the system uses a set of rules to select the appropriate address to connect to first from the available IPv4 and IPv6 addresses for the remote server. One of the considerations here are the historical round trip times toward those addresses—but the IPv6 addresses get a 25 millisecond head start here. These changes make El Capitan favor IPv6 the vast majority of the time in our testing.

Speaking of new network protocols, two years ago we learned that iOS uses Multipath TCP. This is an extension to the regular TCP that underpins virtually all networking, which allows using multiple network paths at the same time. iOS uses this to make Siri switch between Wi-Fi and cellular seamlessly. At this point, it doesn't look like OS X uses MPTCP or that the OS supports applications written for the Linux implementation of the protocol. However, a growing set of sysctls show that MPTCP is actively being worked on in OS X. Apple also has a small open source test program to test MPTCP connectivity.

Explicit Congestion Notification (ECN)

Earlier this summer we mentioned that Apple planned to enable Explicit Congestion Notification in iOS 9 and OS X 10.11. In October 1986, the Internet started suffering from congested network paths. It took several years to clear up this issue by having the TCP protocol that manages the vast majority of the packets that flow across the Internet slow down when it encounters congestion. The way TCP did (and still does) this is by slowing down its transmission rate when it notices that packets are lost, presumably because of congestion. As a result, if a network path becomes congested, the only way the router or switch in question has to signal back to the sending computers that they need to slow their roll is to drop (throw away) some of their packets. Most of the time, that doesn't cause any collateral damage. But in some cases, this will stop TCP in its tracks and leads to user-visible delays.

The ECN protocol, which was published in 2001, aims to solve all of this by allowing routers to tell the communicating systems explicitly to slow down without throwing away their packets. For this purpose, ECN commandeers two bits in the header of IP packets. When both bits are set to zero, ECN isn't used. When one is one and the other is zero, ECN is in play, and routers can then set both bits to one if things get too busy—but the offending packet isn't dropped (unless things get really bad). So now the receiver knows there was congestion along the way, but it's the sender that's in charge of the data transmission rate, so the receiver uses a few other bits in the TCP header to signal back that there was congestion, and the sender gracefully slows down its data rate.

So why aren't we using ECN today, nearly a decade-and-a-half after its invention? Turns out that some firewalls don't like it when bits that traditionally were zero are now one, as Microsoft learned in 2007. Apple itself ran into similar issues when it set the differentiated services bits (which neighbor the ECN bits) to a value requesting "high throughput" in iChat AV 3.0. The result was that some users couldn't video chat at all.

So even though the OS X kernel has supported ECN since 10.5, the OS doesn't negotiate the use of ECN at the start of TCP sessions. According to recent research (PDF), network connections fail about 0.8 percent of the time with ECN bits present. As such, Apple turning on the protocol would be quite a big deal: a small fraction, but still a large number of server and firewall operators would have to scramble to make sure OS X and iOS users would be able to use their services quickly and reliably (although in most cases, fallback to non-ECN communication would probably keep things working.)

Using the public beta period would have been a good way to shake out unexpected issues and allow network operators to make the necessary changes before the OS X- and iOS-using masses start hitting their systems with those ECN bits set. But Apple never turned on ECN in the public betas, so it looks like we'll have to wait a bit longer for the promises of smoother network communication in the presence of network congestion to materialize.

Network security

Apple is taking security very seriously these days. With all the world's most industrious criminals and information-hungry government agencies only a few network hops away, a lot of that security focus is targeted on the network. A good way to make your network communication more secure is using a VPN (Virtual Private Network). iOS 9 and OS X 10.11 (during WWDC, the lines get blurry sometimes) provide hooks for VPN operators.

The network extension APIs allow developers to create extensions that change the behavior of the network. For instance, the operator of a Wi-Fi hotspot network can make an app that will be run in the background by the system if a Wi-Fi network name known to the app is seen, and then the app can log in to the network automatically.

Network extensions can also be used to create apps that connect to personal and enterprise VPNs. The interesting part is that the two types of VPN can coexist: that way, access to the enterprise network will go through the enterprise VPN, while traffic to the Internet at large is routed through the personal VPN. IPv6 is supported both outside and inside IPSec VPN tunnels. Extension apps can have the VPN automatically kick in when certain networks are accessed. Enterprise VPN support goes way beyond IPSec: extensions can implement their own encapsulation. So they can take the IP packets generated by applications and put those into packets of their own making for safe transport over the open Internet.

It's also possible to have per-app VPNs, where only the network traffic generated by certain applications is passed through the VPN. This is especially convenient for organizations that want to manage select apps on their employee's devices.

App transport security

In the Platforms State of the Union session at the World Wide Developers Conference—a second keynote of sorts—developers learned that their applications that use certain common high-level networking APIs will be opted in to App Transport Security. This means that connections must use encryption and authentication best practices: TLS version 1.2 with cryptographic algorithms that provide forward secrecy with a certificate with a SHA256 hash algorithm and 2048-bit RSA or 256-bit ECC or better. These requirements may be tightened in the future as the state of the art evolves. (Forward secrecy means that if someone later obtains the private key used to negotiate session keys, they still can't decode the encrypted data.)

This is an important step to avoid bidding down attacks. This is when an attacker negotiates weaker protections which are then subsequently broken. For instance, in the early days of SSL, the US government restricted exporting of strong crypto. As a result, foreign users of American software were often limited to using 40-bit encryption, which wasn't very strong back in the day and is trivial to break these days. Unfortunately, many Web servers, Web browsers, and other network applications that use SSL/TLS to protect their communication are still set up to accept 40-bit encryption to preserve backward compatibility. So an attacker in the middle of the network can claim to both sides that the other only supports weak encryption. The session is thus (otherwise legitimately) established using 40-bit crypto, which the attacker then feeds to her array of CUDA GPUs for brute force cracking, or similar.

The trouble with Apple's opting applications into network security best practices is that the servers on the other side of the connection aren't necessarily using those same best practices. It looks like Apple applied App Transport Security or something a lot like it to Mail.app in the 10.10.4 update. Suddenly people using ancient mail servers could no longer send e-mail, as the app could no longer connect to the server. Unfortunately, an explanation as to why this was the case wasn't forthcoming, with only a cryptic "CFNetwork SSLHandshake failed (-9850)" message in the system.log. And, strangely, receiving IMAP e-mail over an equally insecure connection was not a problem. The issue seems to be fixed in the 10.10.5 update, although iOS 8.4.1 still won't send outgoing mail using an affected server.

In the case of apps talking to a fixed back-end server operated by or on behalf of the developer, this won't be much of a problem. Developers will be able to test this and correct any issues before pushing out new versions of their applications, or they can set up a list of exceptions. But as the Mail issue shows, the Internet is a big place, so applications that must be able to connect to any given server will likely encounter issues for some users.

Grab bag: Swift 2

It's not directly related to El Capitan, but Apple's Swift programming language has gotten some updates to go along with iOS 9, OS X 10.11, and Xcode 7. Our own John Timmer has already looked at some of the new changes here.

Internationalization and localization

Internationalization and localization section written by Iljitsch van Beijnum

OS X has always been available in a number of languages, but now that two-thirds of Apple's sales is outside the US, internationalization and localization of the OS and applications are more important than ever. Localization means adapting various aspects of the system, such as number, date and time formats, currency, keyboard layout, and language, to different locales. A country can be a single locale or have multiple if multiple languages are spoken in it. Internationalization means setting up the system so that localization is possible. For instance, English uses only the basic unaccented ASCII characters, but OS X uses Unicode, which can encode the characters of all languages, allowing for localization.

El Capitan and iOS 9 add numerous new internationalization APIs that let developers localize their applications. For instance, developers can use a metric representation of weights and measures internally, and Apple's APIs will show values in imperial units if the user has selected those in the System Preferences (or make sure that case conversions use the appropriate conventions). For instance, the Turkish city Diyarbakır should be DİYARBAKIR in upper case and not DIYARBAKIR (first i has a dot even in upper case, second one doesn't have one even in lower case). With the OS set to Turkish, this is indeed what the Edit → Transformations → Make Upper Case menu—well, the Düzen → Dönüşümler → Büyük Harf Hap menu—does.

All of this works quite well when setting up the system in a certain locale and then only using that locale's language, but there don't seem to be any provisions for mixing languages. Before iWork'13, Pages let you tag a document or part of a document as written in a certain language, and then the conventions of that language would apply to that document or that part of the document. Now, it's all or nothing. This is kind of annoying when you're Dutch but write in English a lot. I actually prefer having my system set to English, because some of the Dutch translations make no sense, like "sleep" being translated to "sluimer" (slumber) rather than "slaap."

The American MM/DD/YYYY date format, on the other hand, still makes a beachball spin inside my head when I try to parse it. So I use the Dutch DD-MM-YYYY format. This means all the PDF documents that I make also use that format. I guess I should split the difference and start using the ISO 8601 YYYY-MM-DD format while I wait for Apple to realize that there's not just multiple languages in the world, but they're also used side-by-side by some users. Then again, Apple is in no hurry to make the menu bar clock honor the system time format setting—an issue that hasn't been addressed since at least Mac OS X Leopard.

Another interesting addition to OS X and iOS 9 is that the system now understands the different ways in which names work in different cultures. So is my Mac now going to address me as Ильи́ч van Beĳnum with the original Russian for "Iljitsch" and the Dutch fused Ĳ ligature, properly sorted under the B rather than the V? Sorry, no. The El Capitan Address Book Contacts app is still the same version 9.0 as under Yosemite; its only new feature is "Show contacts found in Mail." It's first name, optional middle name, last name, in that order.

New APIs are a good start, but the benefits won't materialize until developers start using them. In the case of names, this will probably be even harder than with different languages, as it requires users to properly enter first, middle, and last names as well as assorted pre- and postfixes in the correct fields. And as Major Edward A. Murphy, Jr. observed: "If there are two or more ways to do something, and one of those ways can result in a catastrophe, then someone will do it." That brings up the question of how Murphy's name would be parsed by Mail/Contacts. Without much regard to the new name handling APIs apparently, it could be worse: first name Major, last name Murphy.

Safari’s responsive design mode

In addition to its user-facing features, Safari picks up a couple of neat tools for Web developers. To access Safari’s “Develop” menu, enable it in the Advanced tab of Safari’s preferences.

The first is a revamped version of the Web Inspector, which has redesigned tabs and a refreshed look. But the cooler one is a “responsive design mode” that lets you quickly and easily test out a page design using several different user agent strings, screen sizes, and device types.

By default, things are Apple-centric. There are quick presets for each of the four iPhone screen sizes in portrait and landscape mode, portrait and landscape iPads with Split View mode enabled and disabled, and a few different common desktop resolutions. The user agent string can be changed from Mac to iPhone to iPad, but Chrome, Firefox, and Internet Explorer strings for Windows and OS X are supported, and you can drag the size of the viewer to approximate PCs and Android phones if you’d like. It’s handy if you’re working on a responsive design and want to check your work quickly.

Find My Friends

The location-tracking Find My Friends app from iOS has arrived in OS X in the form of a Notification Center widget. Friends who have shared their location data with you will show up in the widget along with their approximate location and distance from you. Double-clicking their locations in the widget will bring the location up in the Maps app.

If you have Find My Friends set up in iOS and your iDevice and Mac are signed into the same iCloud account, Find My Friends contacts will sync between devices.

System Preferences tweaks and new wallpapers

The font and color of the “General” icon in System Preferences has changed to match the font and color of the rest of El Capitan. El Cap also adds a couple of new, El Capitan-focused wallpapers to OS X’s list of them, which otherwise includes all of the wallpapers from previous releases. In the App Store settings, you can optionally set OS X not to require a password when downloading free apps or making purchases and in-app purchases.

Hiding the menu bar

If OS X’s longstanding persistent menu bar has always bothered you, take heart: El Capitan will let you hide and show it just like you can hide and show the Dock. In fact, it works exactly the same way—you can use the reclaimed strip of screen space for apps and hover over the place where it’s hiding to make it pop into view (it will partially obscure any windows you have floating around up there). Full Screen mode could already hide the menu bar, and it works the same way regardless of whether you’ve hidden it or not.

Battery life

Apple isn’t making any Mavericks- or iOS 9-esque claims about battery life in El Capitan, but we figured it was worth the effort to run our standard Wi-Fi browsing test on a couple of different systems and see whether anything had changed. The chart above is the average of two test runs, done on identically configured systems running OS X 10.10.5 and the GM build of 10.11.0.

On a 2015 MacBook, we observed a very small but consistent drop in battery life under El Capitan—a drop of around half an hour, or a little less than five percent. We also noticed a drop on a 2015 15-inch Retina MacBook Pro, but the difference was negligible and within the normal margin of error for a test like this one.

Even the MacBook’s slightly more pronounced drop in battery life is small enough that you’re not likely to notice it in daily use. What you’re doing with the laptop will have a whole lot more to do with how long it lasts. Just know that your experience may vary depending on what you’re installing El Capitan on.

Recommendations

El Capitan on the 2015 MacBook. Credit: Andrew Cunningham

John Siracusa would always end his OS X reviews by making recommendations about whether and when you should upgrade. These questions have become less practical and more rhetorical since Apple made the updates free of charge, but we’ll repeat some of his advice and add some of our own.

First, don’t upgrade until you know your apps are compatible, and even when you do upgrade, make sure you have good Time Machine backups. Waiting for version 10.11.1 to shake out the most obvious bugs is also a good strategy, since that update rarely takes more than a month or so to come out.

While we’ve had few problems getting most apps that work in Yosemite to work in El Capitan, as we mentioned earlier, anything that touches any of the folders guarded by System Integrity Protection will probably need an update to avoid being broken. This includes a bunch of utility apps and drivers that you may have been using without issue in older versions of OS X, so check to see if your hardware manufacturer has released new El Capitan-compatible versions before you take the plunge.

If you do run into edge cases where an app won’t work and you either can’t afford to wait or can’t get new software, disabling System Integrity Protection in the recovery partition (and possibly reinstalling the affected app, since upgrading to El Capitan moves files out of the SIP-protected directories) ought to make things work as they did in Yosemite most of the time. Unless you have a specific reason to turn it off, though, you should leave SIP on—it’s a security feature that’s there for a reason, much like Mountain Lion’s Gatekeeper.

And speaking of Mountain Lion, Apple is almost certainly going to drop extended support for that release once El Capitan is out. The company usually supports the newest version of OS X with point releases that can add larger fixes and new features while providing smaller security-focused updates to the two trailing releases. You ought to be able to get updates for Mavericks and Yosemite going forward, but Mountain Lion is done.

So if you’re using a Mac on the support list but you’re still using 10.6, 10.7, or 10.8, our recommendation becomes more forceful: update. If not now, then soon. Aside from the features you’re missing, you aren’t getting important security updates for the OS or for Safari anymore, and you may be putting yourself at risk.

Conclusions: The importance of the minor update

After Apple’s WWDC keynote, a friend texted me to tell me she couldn't figure out what was supposed to be so great about El Capitan. It's an understandable question to ask, especially after Yosemite's big, immediately obvious changes (and an admittedly grandiose new name).

Almost all of El Capitan's updates are aimed at detail-oriented power users who are intimately familiar with the platform and its apps. I'm sure that not all OS X users even make use of the window management features present in Yosemite, so they're not really in a position to appreciate the improvements in El Capitan. You'd miss pretty much all of Mail's improvements if you don't use trackpad gestures or Full Screen mode. The additions to Safari, Notes, and Maps are all nice but low-key, and things like Metal and System Integrity Protection are, by design, features that don't draw much attention to themselves.

El Capitan follows in the well-worn footsteps of the Snow Leopard or Mountain Lion releases, which introduced some new features but largely focused on polish rather than pizzazz. That’s a good thing for a platform that’s as mature as OS X has become. iOS 9 is a similar kind of release compared to iOS 7 and iOS 8, and the result is the best x.0 version of iOS we’ve gotten in years. Given the breakneck pace of the yearly release cycles, these quieter years are a good opportunity for Apple (and users) to regroup.