OS X 10.10 Yosemite Review

17/10/14 21:49 OS X 10.
10 Yosemite: The Ars Technica Review | Ars Technica

Pagina 1 di 126 http://arstechnica.com/apple/2014/10/os-x-10-10/
OS X 10.10 Yosemite: The Ars Technica Review
Aurich Lawson / Thinkstock
When the book is finally closed on the product line known as OS X, last years
release of OS X 10.9 Mavericks may end up getting short shrift. Sure, it brought
tangible energy saving benefits to Mac laptop owners, but such gains are
quickly taken for granted; internal changes and new frameworks are not as
memorable to customers as they may be to developers and technophiles. And
while Mavericks included many new user-visible features, and even new
bundled applications, the cumulative effect was that of a pleasant upgrade, not
a blockbuster.
But for all its timidity and awkwardness, Mavericks marked a turning point for
OS Xand in more than just naming scheme. It was the first OS X release from
the newly unified, post-Forstall Apple. If iOS 7 was the explosive release of Jony
Ives pent-up software design ethos, then Mavericks was the embodiment of
Craig Federighis patient engineering discipline. Or maybe Mavericks was just a
victim of time constraints and priorities. Either way, in last years OS X release,
Apple tore down the old. This year, finally, Apple is ready with the new.
To signal the Macs newfound confidence, Apple has traded 10.9s obscure
17/10/14 21:49 OS X 10.10 Yosemite: The Ars Technica Review | Ars Technica
surfing location for one of the best known and most beautiful national parks:
Yosemite. The new OSs headline feature is one thats sure to make for a
noteworthy chapter in the annals of OS X: an all-new user interface
appearance. Of course, this change comes a year after iOS got its extreme
makeover.
Ah, the old tension: which platform does Apple love more? iOS continues to
dominate Apples business in terms of unit sales, revenue, and profits. Last
year, some Apple watchers had openly wondered whether Apple would even
bother updating the look of OS X. And yet for the past several years, Apple has
loudly and publicly insisted that it remains committed to the Mac as a strong,
independent platform. Yosemite aims to fulfill that commitmentbut in an
interesting way.
All together now
OS X and iOS have been trading technologies for some time now. For example,
AVFoundation, Apples modern framework for manipulating audiovisual
media, was released for iOS a year before it appeared on OS X. Going in the
other direction, Core Animation, though an integral part of the entire iPhone
interface, was released first on the Mac. Yosemites new look continues the
pattern; iOS got its visual refresh last year, and now its OS Xs turn.
But at this years Worldwide Developers Conference, Apple made several
announcements that point in a new direction: iOS and OS X advancing in
lockstep, with new technologies that not only appear on both platforms
simultaneously but also aim to weave them together.
These new, shared triumphs run the gamut from traditional frameworks and
APIs to cloud services to the very foundation of Apples software ecosystem, the
programming language itself. Apples dramatic leadership restructuring in 2012
put Federighi in charge of both iOS and OS Xa unification of thought that has
now, two years later, resulted in a clear unification of action. Even the most
ardent Mac fan will admit that iOS 7 was a bigger update than Mavericks. This
time around, its finally a fair fight.
Table of Contents
Introduction
Installation
Branding
Yosemites new look
Vibrancy
Animation
Icons
Time Machine
The Dock
Philosophy
Escape hatch
Variations on a theme
Interface changes
Spotlight
Notification Center
Full screen
Open/save dialog boxes
Apple menu
The case of the missing title bar
Applications
Safari
Mail
Finder
Contacts
Game Center
iCloud
iCloud Drive
Family Sharing
Extensions
Extensions in Yosemite
Age of Extensions
Continuity
Handoff
SMS in Messages
AirDrop
Personal Hotspot
iPhone calls
CloudKit
Limits and pricing
CloudKit outlook
Swift
Such great heights
Think fast
Whither SIL?
Frameworks integration
The shape of the future
Grab bag
Activity Monitor
Terminal
Messages
JavaScript automation
System Preferences
General
Desktop & Screen Saver
Mission Control
Security & Privacy
Notifications
App Store
Recommendations
Conclusion
Listing image by Aurich Lawson / Thinkstock
Installation
Software distribution has undergone a long, slow transformation thats been
driven, like so many other things, by the popularization of the Internet. Charts
detailing the schedule and pricing of OS X updates have been a staple of past
reviews, but with Mavericks, OS X apparently reached its final form: free,
download-only, updated annually.
Yosemite maintains the status quo, right down to the list of supported Mac
models, which remains the same for the third year running. Any Mac that can
run Mountain Lion or Mavericks can also run Yosemite. (See our Mavericks
review for a complete list.)
The formula appears to work. While only 35 percent of Mac users had upgraded
to Mountain Lion in the first six months after its release, the majority of Mac
users were running Mavericks after a similar time period. Apple touted OS Xs
improved adoption in its most recent WWDC keynote, calling it the fastest
adoption ever of any PC operating system, and contrasting it with the sluggish
uptake of the two-year-old Windows 8.
Mavericks adoption is well ahead of Mountain Lions 35 percent. As for Windows 8, Tim says eh,
whaddya gonna do?
(A similar chart shown later in the same presentation emphasized how far OS X
still has to go, however; eight months after the release of iOS 7, a full 89 percent
of the installed base was running it. Yikes. Well get em next year, I guessand
a slow start for iOS 8 may make that easier.)
The actual installation process is drama free and should be familiar to anyone
who has upgraded OS X in the past few years. Just hit the Mac App Store, click
a few buttons, and prepare to endure a couple of restarts and a lot of staring at
progress bars.
There is one surprise in store for those who keep a close eye on their disks,
however. Lets start with the simplest possible installation target, a hard drive
with a single HFS+ volume.
% diskutil list
/dev/disk2
#: TYPE NAME SIZE
IDENTIFIER
0: GUID_partition_scheme *1.0 TB
disk2
1: EFI EFI 209.7 MB
disk2s1
2: Apple_HFS Quicksilver 999.9 GB
disk2s2
After installing Yosemite, our simple HFS+ volume has now become the lone
Logical Volume in a newly created Core Storage Logical Volume Group.
% diskutil cs list
CoreStorage logical volume groups (1 found)
|
+-- Logical Volume Group B9CD7D11-BC78-4F74-9FCF-
139406CB6E0E

=========================================================
Name: Quicksilver
Status: Online
Size: 999345127424 B (999.3 GB)
Free Space: 5497978880 B (5.5 GB)
|
+-< Physical Volume 1F0C1FE3-E539-4B5D-BF7C-
B2608215DC14
| ----------------------------------------------
------
| Index: 0
| Disk: disk2s2
| Status: Online
| Size: 999345127424 B (999.3 GB)
|
+-> Logical Volume Family 8579FE70-5A40-4DA5-8858-
97094D
----------------------------------------------
------
Encryption Status: Unlocked
Encryption Type: None
Conversion Status: NoConversion
Conversion Direction: -none-
Has Encrypted Extents: No
Fully Secure: No
Passphrase Required: No
|
+-> Logical Volume 0760311D-CF5A-497F-9D5B-
35F8A69A63EE
------------------------------------------
---------
Disk: disk3
Status: Online
Size (Total): 993494827008 B
(993.5 GB)
Conversion Progress: -none-
Revertible: Yes (no decryption
required)
LV Name: Quicksilver
Volume Name: Quicksilver
Content Hint: Apple_HFS
Core Storage was introduced in OS X 10.7 Lion, ostensibly to support the new,
vastly improved FileVault, Apples whole-disk encryption system. Given the
lamentable state of file system technology at Apple, Core Storage was a beacon
of hope in 2011. OS X 10.8 Mountain Lion came and went in 2012 without any
advancement on the file system front, but Apple had a surprise in store for us
before the year was out: Fusion Drive, also powered by Core Storage.
Here we are in 2014, and HFS+ is still going strong. Yet heres Core Storage
once again, this time without any obvious purpose. Examination of the listing
above reveals that installing Yosemite does not automatically enable FileVault
encryption, and Fusion Drive isnt involved at all in a single-volume installation
scenario.
FileVault, Fusion Drive, and the diskutil man page provide ample evidence of
Core Storages capabilities and purpose, but technical information has been
hard to come by. As far as Im aware, there is no direct, public API for Core
Storage, so a lack of external technical documentation is not surprising. The
limited implementation details about Core Storage provided by Apple make
clear that it does include features found in many modern file systems:
redundant storage of metadata ("ditto blocks" in ZFS parlance) and copy-on-
write B-trees (shades of Btrfs)diminished though they may be by the eventual
layering of HFS+ on top of Core Storage.
Given that Core Storage is a prerequisite for both FileVault and Fusion Drive,
and given that FileVault encryption is now offered as an option during system
setup, the boring explanation for this move is that it just makes sense to apply
Core Storage by default on all Yosemite systemsif only to avoid a second
reboot needed to convert the volume to Core Storage if the user chooses to
enable FileVault during the OS installation process.
But I dont like the boring explanation. In the absence of any contradictory
truths, I choose to believe that this default application of Core Storage is at least
partially intended to lay the groundwork for a future in-place conversion of
HFS+ volumes to a new, superior file system from Apple. (And if you think Im
Charlie Brown to Apples football-holding Lucy on this topic, remember that
persistence is sometimes rewarded)
During the Yosemite setup and account creation process, iCloud continues its
steady march toward the domination of all authentication functions on Apple
platforms. Users who choose to enter an Apple ID when prompted will now be
given a further option, enabled by default, to link their local account and Apple
ID passwords. (This is a step up from the previous option, which merely
allowed a local account password to be reset using a specific Apple ID
password.) Once an account is linked to an Apple ID, attempting to change the
password offers an option either to change the Apple ID password or to divorce
the account from the Apple ID by giving it a separate password.
Having fewer passwords to remember is certainly a good thing, but if you are at
all concerned about the power already inherent in access to an Apple ID
including the potential ability to remotely wipe iOS devices and Macsmaking
your Apple ID password vulnerable to shoulder surfing every time you unlock
your MacBook in a caf or airport may not be a wise choice.
Branding
In past OS X reviews, Apples marketing materials have been mined for hints
about the companys intentions. In the absence of any dramatic visual changes
to the software itself, ancillary content like retail product packaging (back when
OS X was a physical product), Apples OS X website, and even the default
desktop background must fill in the gaps to make each new OS X release into a
coherent, distinct product in the minds of customers who have not yet installed
it.
Enlarge / Apples Yosemite website: startlingly thin text and a wall of granite seen through a haze.
Yosemites branding initially seems a bit on-the-nose, leaning heavily on El
Capitan and Half Dome, two of Yosemite National Parks most iconic features.
But the other repeated element, the wispy cloud partially obscuring the rock
face, is actually a strong hint of things to come.
As well see in a moment, Yosemite is less in need of external visual
augmentation than any release of OS X since 10.0. Thanks to Yosemites
comprehensively resurfaced UI, every screenshot is part of the branding.
Yosemites new look
In the months leading up to the release of iOS 7, conventional wisdom held that
the era of skeuomorphism in Apples user interface design was drawing to a
close. In its place, Apple watchers expected a flatter style similar to
Microsofts Metro UI, introduced in Windows Phone 7 and later extended to
Windows 8.
Despite what seemed like widespread agreement that stitched leather and tiny
strips of torn paper were a bridge too far, the anti-skeuomorphism backlash
was already forming a backlash of its own. One month before Apple revealed
iOS 7 at WWDC 2013, Panic designer Neven Mrgan cheekily explored the
continuum:
Are you undecided in the great Flat vs. Skeuououmourphic design debate
of 2012? Are you unsure of how flat is flat enough (but not too flat)?
Wondering what it means to let a button be a button? Use this handy
chart to pick the button that looks like a button to you!
Reflecting on his post in light of the eventual reality of iOS 7, Mrgan mused that
the joke options in his image turned out to be exactly what we got: buttons
consisting of text labels and nothing else.
iOS 7 buttons: just the text, maam.
Apple has tried to explain to developers the contexts in which label-only
buttons work best, and it has conceded that in some situations, drawing
borders around buttons is still the best choice. In iOS 7.1, Apple went further,
adding a system-wide option to enable button shapes.
Ive rehashed this recent iOS history to set the stage for Yosemite. As with iOS
7, a redesign was expected in OS X 10.10. But this time, we knew exactly how
far Apple was willing to go. Visions of a radical new OS X danced in our heads:
impossibly thin Helvetica text, no shadows below windows, application icons all
forcibly contained in rounded rectangles, every toolbar icon reduced to
monochromatic wireframes, every button transformed into a simple text label,
and whiteeverywhere, white!
Lets start with the most basic interface element, the title bar. Heres where we
were in Mavericks:
A Mavericks window title bar.
And heres Yosemite:
A Yosemite window title bar.
So far, so good, right? The traffic-light widgets are flattened, as expected,
transforming from glossy gumdrops to flat circles. The title bar itself is lighter,
but its hardly stark white. The system font (as seen in the window title) has
changed from Lucida Grande to Helvetica Neue.
I expect the font change to be well below the radar of the vast majority of Mac
users, but it is (perhaps surprisingly) relevant to developers. Though Apple has
gone to some lengths to keep the metrics similar for both fonts, text rendered in
Helvetica Neue may be either longer or shorter than the same text rendered in
Lucida Grande, depending on the exact sequence of characters. When
applications that were built against the Mavericks SDK or earlier are running
on Yosemite, the system will compress the spacing in any text that uses the
system font if it becomes too large for its container. This may be ugly in places,
but squished beats truncated any day.
Moving on from the title bar, Yosemites standard controls are similarly
reassuring. Heres a sampler:
Yosemite standard controls.
Compared to the Mavericks equivalent, Yosemite knocks down a lot of the
depth, surface detail, and shadow lines while also cranking up the saturation in
the blue highlight color. Without the gleam and polish of its predecessors,
Yosemites new look relies on crisp edges and fine lines.
While Mavericks on a Retina display sometimes dipped into the uncanny valley,
looking almostbut not quitephotorealistic, Yosemites design plays to
Retinas strengths. On non-Retina displays, Yosemite seems uncomfortable,
descending into soft-edged blandness. If Retina desktop Macs still havent been
announced by the time you read this, Apple had better hurry up.
Control metrics have not changed much, but some of the new visuals are
striking. Progress bars are considerably simplified, transforming from shiny,
puffy, pulsating barber poles to mere strips of blue, with a subtle gradient detail
in the indeterminate progress bar only. Also note the centering of the
placeholder text in the search field.
But most importantly, buttons and other controls still have recognizable shapes
and are clearly distinguished from the background. Several controls even have
gradients to indicate some surface curvature. If this is flat design, its flat design
with an asterisk, at the very least. It seems like we were all worried for nothing.
But dont get too comfortable
Vibrancy
Yosemite has one more trick up its sleeve, and its a doozy. Take a look at this
Finder window:
In Yosemite, uniform gray toolbars and sidebars are transformed into well, something else.
While title bars and standard controls may look reassuringly familiar in
Yosemite, toolbars and sidebars (source lists, in Apples parlance) subvert their
plain gray coloring by allowing other content to leak through. Apple calls this
new effect vibrancy. In addition to the expected transparency and blur filters,
vibrancy also intensifies and pulls forward the color information from the
background.
In the screenshot above, note the colors bleeding through the title bar from the
image thumbnails that are scrolling up behind it. This is the within window
blending mode, where content inside the window itself (usually in a scrolling
view) shows through other interface elements in the same window. In the
sidebar, the orange sky and outline of the mountain from the desktop
background are faintly visible. This is the behind window blending mode; it
shows whatever is directly behind the window, whether thats the desktop or
another windowbut it always mixes in a hint of the desktop picture.
Yosemite has dark and light vibrancy appearances, plus a special material
specifically for window title bars. The effect is subtle and should be familiar to
anyone who has used iOS 7.
The same image shown unmodied and with dark and light vibrant appearances applied.
Vibrancy is used throughout the OS, including in nearly every transient or
otherwise layered interface element: pull-down and context menus, sheets,
the menu bar, Notification Center and associated alerts, and even the Dock. The
filter settings appear slightly different in each of these contexts, but the family
resemblance is clear.
Vibrancy in action. (Composite screenshot. Closed course. Do not attempt.)
Vibrancy is not limited to standard controls or to the OS itself. Third-party
developers can apply it to any view within an application, choosing both the
blending mode and the appearance. Furthermore, source lists used in third-
party applications will automatically get the new translucent look, as will any
toolbar with an adjacent scrolling view.
Its surprising to see such dramatic appearance changes applied by default to
third-party applications (though this is somewhat moderated by the specific
technical details of what constitutes a source list and an adjacent scrolling
view), but it does show how committed Apple is to this look. Expect to see it
everywhere in the OS, in all major bundled applications, and in at least a few
third-party applications.
These visual effects arent free; they cost CPU and GPU cycles each time the
foreground or background changes. Behind-window blending is implemented
in the window server, which is responsible for compositing all the visible
windows into the final screen image. (This compositing process has been GPU-
accelerated since 2005.) Moving a window that uses vibrancy in the behind-
window blending mode does not require the application that owns the window
to redraw any content; the window server handles the re-compositing as the
background changes.
Within-window blending, on the other hand, is handled by each individual
application. The system frameworks use Core Animation layers (also GPU-
accelerated) to apply the necessary filters, blending, say, the contents of a
scrolling view with the toolbar that partially covers it.
Given Apples recent focus on energy saving in Mavericks, its a bit strange to
see Yosemite lean so heavily on a dynamic effect like vibrancy. To keep things
from getting out of hand, vibrant views become opaque when inactive. In
practice, this means only the front-most window in the currently active
applicationplus the Dock, menu bar, and any notification alerts that may
dance across your screenwill burn cycles artistically blending foreground and
background content.
Animation
Many standard controls now have state-change animations in Yosemite. The
various fades and zooms are fast and subtle, for the most part, though the
shrink-to-fit focus ring animation might be a bit over the top. See for yourself in
the movie below.
Standard control animations in Yosemite. Could be worse
Is this really the same Apple that, just last year, disabled the Time Machine
menu bar icons animation, presumably for energy-saving purposes? To be fair,
there is a significant difference between brief animations triggered by user
input and continuous animations that run whether the user is present or not.
Though Yosemite may indulge in the former, Apples crusade against the latter
continues.
Consider the default button in a dialog box. Since the very first version of OS X,
default buttons have changed their appearance many times but have always
retained a subtle pulsing animation. That animation is gone in Yosemite;
default buttons are just as static as non-default buttons. (The Time Machine
menu bar icon animation has not returned, either.)
Icons
Fears of an iOS-style round rect icon revolution on the Mac may have been
unfounded, but Apple is trying to discipline the world of OS X icons. While one
icon shape has been deemed insufficient, Apple believes three shapes should
just about do it: circle, rectangle, and tilted rectangle.
Launchpad, System Preferences, and Font Book demonstrate Apples three recommended icon shapes.
The circle and rectangle shapes are long-standing traditions on OS X. The tilted
rectangle is slightly different than the icon style it replaces in that the
projection is now orthographic; areas further from the camera are no longer
smaller, as they would be in a perspective projection.
Most of Apples tilted rectangle icons still represent tangible things: pads of
paper, tiny books, photographs, gadgets. Its the surface details that really
differentiate Yosemites icons. Visual simplification is the order of the day, and
details that dont read well at small icon sizes have been excised. The new style
makes the icons look slightly more, well, iconic. Theres also a bit of mood
lighting at work here, as if each icon exists in an eternal magic hour just
before sunset.
Icon evolution: Mavericks in the top row, Yosemite in the bottom row. The Yosemite strategy: omit
needless details; matte nish instead of glossy; no vanishing point.
Some application icons have not been updated at all, but among those that have
been refreshed, I see only a few misses. Terminal has been robbed of all
character and flair, now appearing as an almost featureless black rectangle
whose connection to Apples latest display hardware takes a sharp eye (and
maybe a Retina display) to discern. The chunky QuickTime Player icon
introduced five years ago has been revisedfor the better, I thinkbut its still
not much of a looker. If I really want to pick nits (and I do), the FaceTime icons
telephone badge obscures the camera shape, producing a green jumble. (Both
shapes are also anachronisms.)
Less-successful icons: QuickTime Player is (still) too chunky, Terminal is too plain, FaceTime is too
confused.
Finally, consider that most quintessential of icons, the humble folder. No longer
open a crack like its predecessor (or if it is open, then orthographic projection
hides the fact), the Yosemite folder is, perhaps, less inviting. But the shape is
less noticeable than the color: a swimming-pool-caliber blue-green.
Folder icons: Mavericks on the left, Yosemite on the right. Out with the old and in with the (brighter) blue.
Of all the visual elements in Yosemite, this is the one that doesnt seem to fit in
with the rest. Instead of being bathed in the light of a sunset, these folders look
like color chips from a 70s bathroom tile catalog. And theres not much
harmony between folders and the highlight colors used on controls like default
buttons and pop-up menus. Still, Im willing to believe a little friction can add
interest to a design.
Time Machine
Time Machine debuted as one of the most flamboyant features Apple has ever
added to OS X, both in terms of ambition (make backup easy enough that
anyone can do it) and user interface (make backups fun, so people will want to
do it).
But just as the days of stitched leather have come and gone on the Mac, so too
has the era of the non-functional swirling space vortex background. In its place,
Yosemite offers standard-looking buttons and a now-familiar blurred
background.
The Time Machine vortex has collapsed, leaving behind a uniform haze.
The Dock
The 3D Dock introduced in Leopard has remained a sore spot to those with a
special sensitivity to visual incongruity. The surface details have changed in the
years since, but Apple has continued to render the Dock as a virtual shelf upon
which application icons (uncomfortably) sit.
While its horizontal cousin was tripping the light fantastic with real-time
reflections and machined edges, the vertical Dock stuck to a simple, two-
dimensional look. In Yosemite, the two Dock appearances have finally become
one. Vanishing points and surface textures are out; vibrancy is in.
Vibrancy replaces metal in the Yosemite Dock.
The Yosemite Dock aggressively pulls background colors forward, more so than
even the relatively transparent pull-down and context menus. A different
background image can have a dramatic effect on the appearance of the Dock.
(Also note the trash cans new, smoky look that matches well with the rest of
the system.)
The many faces of the Yosemite Dock.
Apples ongoing war against whimsy continues with the retirement of the
adorable puff-of-smoke cursor and subsequent animation when removing an
item from the Dock. In its place, Yosemite shows the word Remove while
dragging, and it simply makes the icon disappear upon release. Along the same
lines, the glowing indicator lights shown under running applications have been
replaced by straightforward (tiny) dots. Progress bars on Dock items are thin
stripes of black ink.
Dock item removal, progress bar, and running indicators. (Composite image; ignore the double mouse
cursors.)
Its worth noting that this is the first time in many years the Dock has used the
same appearance in both its vertical and horizontal positions. Setting aside the
particulars, the Yosemite Dock exudes a visual confidence that has been sorely
missed in the past few releases of OS X.
Philosophy
For the most part, a new look for an operating system doesnt need to justify
itself. Its fashion. We all want something new every once in a while. It just
needs to look good. But things start to get complicated when fashion butts
heads with usabilitythen we want reasons.
Though Ive tiptoed around it thus far, the friction point in Yosemites new
visual design is its pervasive use of transparency. (Technically, translucency is
more accurate, but please indulge my idiomatic usage.) Allowing whats behind
to influence the appearance of whats in front is problematic in a couple of
ways. From a purely aesthetic perspective, transparency is unpredictable.
Designers can decide which aspects of the background will influence the
foreground image, but they cant control the content of that background. Will
its contribution make the final image more pleasing, or will things turn ugly?
In terms of usability, transparency risks impairing readability and recognition.
Colors bleeding through from other content can undermine the intended
contrast between text and its background. Symbols and shading meant to
subdivide an interface can be sabotaged by the influence of unrelated
background images. The content as designed by the application developer is the
signal; any background content that shows through is noise.
This is not Apples first transparency rodeo, however. Early versions of OS X
faded some interface elements almost to the point of invisibility. The look made
for a nice demo (14 years ago, anyway), but readability was severely
compromised in some cases. The problem was exacerbated by the lack of
additional image processing (e.g., blur) applied to the background. (At this
point in OS Xs history, all compositing was done on the CPU.)
Later versions of OS X toned down the transparency and eventually
incorporated additional effects to make background content even less
distracting. In Leopard, Apple once again succumbed to the siren call of
transparency, deciding the world really needed to see more of whats behind the
menu bar. In another repeat of history, pre-release builds of Leopard included
even more extreme transparency, which was moderated before release. (Menu
bar transparency was eventually made optional in 10.5.2.)
Apple has taken great pains in Yosemite to ensure that any content that does
show through transparent interface elements is extremely diffuse and
indistinct. But the aspects of the background that do show throughmostly
colorare often magnified.
Inevitably, I find myself searching for a reason. Why is it important for me to
see any aspect of whats behind the front-most active window? Why risk
reducing both the usability and attractiveness of the UI? To what end?
Apple has offered many different justifications for this aspect of Yosemites new
look. In the WWDC keynote, Craig Federighi explained in-window blending in
the Findericons scrolling behind the toolbarby saying, The use of
translucent materials gives you a sense of place as you scroll your content.
Given the disappearing scroll bars introduced in Lion, a vague, colored haze
showing through the toolbar may indeed be the only indication that more
content is available above the currently visible region, but Im not sure how
strong that signal will be to most people.
Federighi also described translucency as a tool for visual customization. Now
your windows take on the personality of your desktop. As you change your
desktop picture, your window adapts to reflect that personality and that
temperature. This works best if theres nothing between a window and the
desktop background. The strongest influence on the personality and
temperature of a window on a busy OS X system is the content of some other
window, which is more difficult to control than the desktop picture.
(The most obvious demonstration of this aspect of vibrancy is the menu bar. It
pulls color from the desktop picture behind it, but this color also appears in
each pull-down menu. Even if a completely white window is behind a pull-
down menu (or any other vibrant surface), it will be tinged with the color of the
desktop background.)
In a later WWDC session, Mike Stern, a User Experience Evangelist at Apple,
espoused the idea that software interfaces should have plausible physical
dimensionality and that this dimensionality helps the user to focus on the
things that are in the foreground and pay less attention to those things which
are in the background. Stern noted aspects of OS Xs design (like gradients and
drop shadows) that contribute to dimensionality, but he also cited the use of
transparency in elements like Notification Center.
I dont think Notification Center, menus, and the Dock need to be transparent
for me to understand that theyre on top of the other things on the screen. Even
setting aside the drop shadows, the fact that these interface elements are drawn
on top of everything else gets the point across just fine.
Theres a kernel of truth in Apples justifications for the widespread use of
transparency in Yosemite. Surprisingly, the one I find myself agreeing with the
most is transparency as a vector for personalizationor, at the very least,
variety. As noted earlier, the Yosemite interface really does look quite different
depending on whats behind the various translucent interface elements. Im not
sure how much control users will have over this aspect of the experience, but at
the very least, the desktop picture can spread its tint to all vibrant surfaces
while also strongly influencing the menu bar and the Dock (assuming people
dont slide windows behind it).
As much as I may support any of these lines of reasoning, my tolerance for any
instance of impaired readability due to background leakage is very low.
Others feel differently, Im sure, but I find myself wishing that Apple had
chosen an attractive, signature look for non-transient elements like windows
and sidebars that was based on completely opaque artwork. Interestingly
enough
Escape hatch
One rationale Apple hasnt emphasized much is that transparency makes the
interface more attractive. One might assume this is implied; Apples not the
kind of company known for adding visual effects to aid usability at the expense
of aesthetics.
Of course, thats exactly what Apple has always done with its accessibility
features. Massive magnification or an inverted color palette do not make for
attractive screenshots, but these features make OS X more usable for people
with certain kinds of visual impairments.
Yosemite includes a new reduce transparency option in its Accessibility
preference pane, aimed at addressing possible usability problems created by the
OSs new look. Enabling this option removes transparency nearly everywhere.
The Dock, menu bar, toolbars, sidebars, context menus, sheets, Notification
Centerall completely opaque.
A completely opaque Yosemite is just one Accessibility preference away.
Opaque Yosemite doesnt look bad at all. Its a little boring, perhaps, especially
the Dock, but I can imagine almost anyone using it and being satisfied. This is a
testament to the design of Yosemites new look; it may (or may not) benefit
from transparency, but it doesnt rely on it to look good and work well.
Theres also an increase contrast option that activates reduced transparency,
increases the contrast between text and its background, and draws darker,
thicker outlines around most standard controls. It looks a lot like someone has
taken to your screen with a fine-point marker.
The increase contrast Accessibility setting is subtle. Note the slightly darker button outlines and sidebar
text.
Visually speaking, this is all a lot to take inand weve barely scratched the
surface of Yosemites interface changes beyond its new coat of paint. Well get
to that in the next section, but before we leave the world of colors and finishes,
theres one more twist to consider.
Variations on a theme
In the early days of OS X, I remember reflexively checking the General
preference pane in each new pre-release build of the OS to see if the
Appearance pop-up contained more than just the Blue and Graphite
options. Back then, the Mac was coming off an era of unprecedented
appearance customization capabilities. Steve Jobs returned to Apple just in
time to nix the release of Apples own alternate appearance themes, but he was
too late to stop the release of the framework that made classic Mac OS themes
possible: the mighty Appearance Manager.
Third-party system extensions like Kaleidoscope rushed in where Apple feared
to tread. I had hundreds of Kaleidoscope schemes (as they were called), plus
Apples own, unreleased Hi-Tech, Gizmo, and Drawing Board themes. Truly, it
was a golden age.
All these years later, OS X still offers the same two appearance options: Blue
and Graphite. In Yosemite, the Graphite option is finally much closer to a
completely neutral gray than the blue-tinged gray that preceded it. This should
be a boon to people who work with color and dont want to be unduly
influenced by the interface chrome. (For me, Graphite will always be the
boring option.)
Yosemites Graphite appearance theme: for when color is the enemy.
Yosemite does have one surprise up its sleeve, however. The General preference
pane contains a new option to switch the menu bar and Dock to dark
backgrounds with light text. The command-tab switcher and Spotlight interface
also adopt the darker theme, but window chrome and standard controls remain
unchanged.
Looks like everythings coming up Mrgan in Yosemite.
Midnight is where the day begins.
The return of the Appearance Manager its not, but the look does have a certain
sinister appeal. Reinforcing the reality that the days of theme-savvy interface
APIs on the Mac are long gone, dark-mode aficionados can expect to see some
third-party menu bar icons that blindly draw themselves and/or their menu
contents in black, leading to an unreadable black-on-black appearance. (The
recommended usage of the relevant NSStatusItem class has been heavily
revised in Yosemite; developers have some work to do.)
The potential for similar bugs in the interface of applications themselves might
explain why the dark theme doesnt extend to more of the interface. As it
stands, the theme is so limited that some people may wonder why its included
at all. Apple says this feature was motivated by a desire to tone down the
brightness of these always-visible interface elements and to better match the
dark UI of pro applications like Aperture. Whatever the reasons, after all these
years of just Blue and Graphite, Im excited to see Apple dipping its toe back
into the world of appearance customization.
Interface changes
Design, as they say, is not just how something looks and feels. Design is how it
works. The entire interface doesnt just look different in Yosemite; major pieces
work differently as well.
Spotlight
Following in the footsteps of venerable quick-access launchers like LaunchBar
and Quicksilver as well as (relative) youngsters like Alfred, the Spotlight search
field now appears front and center when activated. This may seem like a trivial
change, but it transforms the user experience. What was once an awkward,
non-standard text field sprouting from a tiny icon in the corner of the screen is
now a wide, inviting window with very large text.
Spotlight, now front and center.
A preview area has been added to the results window, providing a quick look at
the highlighted result. Spotlights purview has expanded to encompass
locations (via Apples Maps), digital media (iTunes), software (the App Store),
and results from well-known websites like Wikipedia, all with nice inline
previews.
Spotlight search results: more sources, richer previews. Also note the search query autocomplete feature.
The up and down arrow keys can be used to select (and preview) each result.
Holding down the command key when a file or folder result is selected will
display the path to the item.
In addition to the simple mathematical calculations it already handles,
Spotlight in Yosemite now does unit conversions faster than you can type the
same query into a Google search box.
Spotlight unit conversion.
As always, all these data sources can be toggled using the Spotlight preference
pane (though its sometimes difficult to tell which source is responsible for a
result).
They may all seem like minor changes, but the cumulative effect is significant.
The interface looks and behaves differently enough that I suspect some people
may view it as an entirely new feature rather than a simple evolution of
Spotlight.
The aforementioned third-party launchers will likely always have more features
and customizability, but Spotlight in Yosemite is the first version that actually
has a shot at keeping me from immediately installing my own preferred
launcher on any new system. (The one basic feature I miss is the retention of
the previous search between activations. This makes re-launching the
previously launched applicationa common occurrence in post-auto-
termination OS Xas simple as typing command-space and then hitting
return.) For anyone who has never even heard of this entire category of
launcher applications, the new Spotlight is a big step in the right direction.
Notification Center
Notification Center changes its appearance, animation, and purpose in
Yosemite. It still slides out from the right edge of the screen, but its now a sheet
of dark vibrancy that overlaps the screen rather than pushing the entire screen
image to the left. A tab bar at the top switches between the interfaces two
functions: displaying notifications and showing an iOS-style Today view.
Everything thats not a notification (e.g., the widget used to send an instant
message or write a tweet) has moved into the Today view.
Notication Centers new Today view. The sidebar no longer pushes the entire desktop to the left, but it
does still push notication alerts, as shown above.
The contents of the Today view are almost entirely customizable. The day and
date cannot be removed from the top (which is a shame), but every other item
can be reordered or removed (though the Today and Tomorrow widgets seem
stuck at the top and bottom, respectively). Individual widgets can be configured
by clicking an easy-to-miss i-in-a-circle icon that appears in the upper-right
corner of each widget on mouse-over. Most importantly, installed applications
can add new Notification Center widgets (through a mechanism that will be
explained later).
Editing the contents of Notication Centers new Today view.
If this sounds a lot like Dashboard, its no coincidence. Though Dashboard still
exists in Yosemite (now with a Launchpad-like blurred background), it hasnt
had any noteworthy updates in years. I would not be surprised to see
Dashboard disappear in the next major release of OS X. After 10 years, its had
a good run, but Apple is clearly ready to move on.
Full screen
Its not often that the window title bar changes on the Mac, so when the full
screen widget appeared in Lion, occupying the former home of the short-lived
and fabulously purple single-window mode toggle, it demonstrated Apples
commitment to this new feature.
In Yosemite, full-screen mode graduates to the next level, evicting the former
functionality of the green stoplight widget. The far right corner of the standard
OS X window title bar is now, once again, completely empty.
The full-screen API and its functionality are unchanged; only the interface is
different. When an application supports full-screen mode, the green title bar
widget contains a tiny zoom icon instead of the traditional plus sign.
If you squint, you can just make out a tiny full-screen icon hiding in the green window widget.
Holding down the option key when clicking the green widget (or just double-
clicking the title bar) will restore its pre-Yosemite appearance and behavior. If
you dont know what the pre-Yosemite behavior was, well, youre probably not
alone; it varied from application to application. Full-screen mode is the same
everywherebut not every application supports it. Im all for interface
simplification, but this is still not quite a solved problem.
Open/save dialog boxes
Open/save dialog boxes have dropped some weight in the toolbar region thanks
to the removal of the iCloud/Mac mode switcher added in Mountain Lion. (The
iCloud Drive item in the sidebar replaces it.) The dialog box otherwise looks like
a Yosemite-ized version of its former self, but there are a few new, hidden
features.
Dragging a file from the Finder into an open/save dialog box will still cause the
dialog to switch to the files parent folder (selecting the file if its an open
dialog), just as it has done since time immemorial. Yosemite adds modifier keys
to the mix.
Holding down the command key while dragging files to and from an open/save
dialog will actually move the files. For example, command-dragging a file from
the Desktop into an open dialog box currently showing the Documents folder
will move the file from the Desktop to the Documents folder. Going in the other
direction, command-dragging a file from an open/save dialog box to the
Desktop will move it there.
The story is the same for option-drag, but the file will be copied instead of
moved. Command-option-drag will make an alias of the file. All of this works
for folders as well as files, of course. Finally, the context menu that appears
when right-clicking (or control-clicking) an item in an open/save dialog now
includes options to duplicate it or move it to the trash.
New actions available from open/save dialog boxes: Rename, Move to Trash, and Duplicate.
If youve been a Mac user long enough to remember Boomerang, the popular
open/save dialog enhancer for classic Mac OS, then you know Apples standard
implementation of this ubiquitous interface element has always been somewhat
lacking. Today, system extensions like Default Folder X continue to highlight its
shortcomings. Yosemites open/save dialogs do not close that functional gap,
but its nice to see Apple finally making some progress.
Apple menu
The Apple menu gets a minor reorganization in Yosemite. The separate
Software Update item is gone. Pending updates are now indicated with an
in-menu badge on the App Store item. The Dock menu item has also
departed. Sadly, the System Preferences item still does not sprout a sub-menu
to allow quick access to preference panes. In happier news, About This Mac is
back to its rightful place as the sole item in a separate section at the top of the
menu.
The new Apple menu (in dark mode, to spice things up) showing o! its new organization and software
update badge.
The case of the missing title bar
The earlier Finder screenshot contained all the expected parts at the top of the
window: a title bar with its three stoplight widgets on the left and some title text
(and a proxy icon) in the middle; below that, a customizable toolbar with
groups of buttons. Now lets look at the top of the Maps application window.
The Maps application provides an example of the new combined title bar and toolbar.
The stoplight widgets remain, but the title bar as we know it is gone. In its place
is a toolbar that starts just to the right of the vertically repositioned stoplight
widgets. In this case, the content of the window scrolls up behind the new title
bar/toolbar hybrid and is faintly visible thanks to in-window blending.
The most obvious advantage of this new arrangement is its compactness. The
traditional title bar takes up roughly 22 points of vertical space and usually
contains only the window widgets, some title text, and maybe a proxy icon. The
wider the window, the larger the proportion of empty space in the title bar.
The new combined arrangement reclaims that vertical space for use by window
content. Mac screens are almost always wider than they are tall, so vertical
space tends to be more precious than horizontal space. According to Apple,
content-focused design is another theme of Yosemite. Where possible, the
visual and conceptual weight of the user interface is minimized and the content
gets more space and emphasis.
The disadvantages of this design are also obvious. All the empty space in the
traditional title bar actually served a purposeproviding a safe place to grab
the window for dragging. The compact design drastically reduces the draggable
area.
The empty space around the central set of toolbar items in the Maps screenshot
above is an attempt to alleviate this problem, but it works best when the
window is very wide. Maps addresses this problem by mandating a minimum
width for the window. Safari, another application that uses this design, will hide
toolbar items as the window gets narrower, shunting them off to a chevron pop-
up menu.
Safari attempting to preserve draggable area around the location eld by pushing toolbar items into an
overow menu.
Theres also a cruelly tempting 4-5 points of draggable vertical space above the
toolbar items (and below the point where the window resizing cursor appears).
For years, Chrome on the Mac has had a similar title-bar-less design, but with
roughly double the vertical space available for dragging above the line of tabs.
Chromes attempt to preserve draggable area at the top of the window.
Im all for conserving vertical space, but I dont like the idea of window
movement gradually turning into a draggable region scavenger hunt.
Lets not forget the other function of the traditional title bar: displaying the
window title. Document windows should show the document name as the
window title and therefore shouldnt adopt the compact style that removes the
title entirely.
The choice is less obvious for non-document windows. The Maps application
puts the search field where the window title would be. This is a reasonable
alternative to a static window title like Maps. It is a bit confusing, however,
that the name shown in the Window menu is based on the current map
location, which usually doesnt match the text in the search field. Safari puts its
newly neutered address/search bar in place of the window title, but it mostly
sidesteps the window title problem by showing an intelligently truncated
version of the page title on each tab.
For predominantly single-window applications, theres often no sensible
window title other than the application name. Apples solution for those
applications in Yosemite is even more extreme. Compare the Notes application
in Mavericks and Yosemite.
The window title for Notes in Mavericks combines the application name and the title of the currently
selected note.
Notes in Yosemite has no title bar or window title at all.
Notes in Yosemite incorporates the window widgets into the leftmost sidebar
and surrenders the rest of the space traditionally occupied by the title bar to
application contentvisually, anyway. Theres still the usual amount of empty
space at the top of the window available for dragging; it just happens to be
styled to match the various regions of application content below it.
Despite maintaining the same draggable area, some vertical space is saved by
allowing window content to nestle up against what would normally be the hard
dividing line between a traditional title bar and the window content. In other
words, the margin above the window content has been collapsed.
This is a clever design with fewer compromises than the combined title
bar/toolbar used in Maps and Safari, but it still has some pitfalls. The lack of a
clear division between window content and the title bar can lead to failed drag
attempts when the cursor lands just below the valid draggable area. This design
is also only feasible for applications that are not document-based and usually
show just a single window. Luckily, many such applications are bundled with
OS X.
Invisible title bar examples, from top to bottom: Reminders, Notes, Contacts.
All these title bar configurations are available to third-party developers via new
window properties and APIs. These can be arbitrarily mixed and matched to
create new designs beyond what Apple has done.
Overall, this monkeying with the title bar seems like a milder version of Apples
interface experimentation in Lion. In both cases, bundled applications are the
test subjects. In Yosemite, however, the new features are immediately available
to third-party developers as well.
Applications
Every application seems new in Yosemite thanks to the system-wide visual
overhaul. Many applications have been rearranged to take advantage of new
title bar configurations. And a few have been given entirely new interfaces.
Here are some of the highlights.
Safari
Yosemite ships with Safari 8, the most substantial visual update to Safari since
the aborted Safari 4 betas toppy tabs. We already covered most of the
changes to Safaris toolbar, but tabs add an unexpected twist. Since Safari uses
in-window blending, changing tabs within a single window immediately
changes the content scrolling up behind the toolbar. This means the same
window can change its appearance in dramatic ways as you cycle through tabs.
Switching tabs within a single Safari window can drastically a!ect its appearance. These are not four
separate windows! This is one window, and were calling it Safari 8.
Theres a new option (enabled by default) to show Spotlight suggestions in Web
address search results. This includes the full range of possible Spotlight sources
(Wikipedia, iTunes media and apps, map locations, movies currently in
theaters, etc.), but only the top result is shown in Safari.
Spotlight suggestions in Safari address bar search results.
One more new toolbar-related feature will surely raise some geek eyebrows.
When the combined address/search bar does not have the input focus, it no
longer shows the full URL of the current page. Instead, it shows just the domain
name (e.g., apple.com) or, if the current page was loaded via SSL with an
extended validation certificate, a padlock icon and the organization name
associated with the SSL certificate in green text.
The URL of this page is http://www.apple.com/watch/, but only apple.com is displayed.
This page uses SSL with an extended validation certicate. Only the name of the requesting entity is
shown.
The new address bar looks nearly identical to the one in Safari for iOS. On an
iPhone, horizontal space is so constrained that the choice not to show the full
URL is understandable. On an iPad, this is less true, but theres an argument to
be made for consistency. On the Mac, however, horizontal space is abundant,
and pixel-for-pixel symmetry with iOS is decidedly out of fashion.
There are at least two other reasons to bring this interface to the Mac, however.
The first is security. When the full URL is shown, its possible to fool users into
thinking they are on a familiar website when theyre actually on a phishing site.
One way to do this is by using a very long domain name that happens to begin
with what looks like a legitimate domain name. For example, in the screenshot
below, the URL may appear at first glance to be a Google search, but its
actually a very long subdomain of my-malicious-site.com (which is not visible
because the address bar is not wide enough).
A simple phishing attack using a very long domain name.
Apple is not the first browser vendor to consider drastic measures to address
this issue. Google recently experimented with replacing the URL with what it
calls an Origin Chip. Googles explanation of this change cites both security
concerns and the precedent set by iOS.
All major desktop browser vendors, including Apple, have existing features
meant to combat URL-based phishing attacks. These features usually add new
elements to the address bar that cannot be faked by confusing URLs (e.g., a
separate badge showing the owner of the sites SSL certificate). Some browsers
also display the domain and path portions of URLs in different text colors or
weights. But all of these approaches suffer from the same problems that enable
the very phishing attacks theyre meant to prevent: inattention and confusion.
The people who dont notice or dont know how to interpret these subtle signs
are exactly the people most in need of help.
This leads to the second reason to bring the iOS-style address bar to Safari on
the Mac: simplicity. Though we technology enthusiasts may consider URLs an
integral and well-understood part of our Web browsing experience, the vast
majority of people have little interest in URLs beyond the one part of them that
is commonly understood: the domain name. Everyone knows what google.com
is, but few people know or care about the alphabet soup of text that may follow
the domain name.
If you accept this premise, the iOS-style design follows naturally. Rather than
adding elements to the address bar or trying to visually differentiate the
components of the URL, Apple has chosen to reduce the visible address to the
one part that people understandwhich also happens to be the one part that
matters when it comes to avoiding URL-based phishing attacks.
If you dont accept this premise, well, chances are good that you know a bit
more about computers than the average personbut that doesnt necessarily
mean youre wrong. I confess, I also have my doubts about the complete
irrelevance of URLs. Even if most people dont understand the details, good
URL design can and should use the address bar to convey location information
beyond just the domain name. This is especially true given the dismal state of
page titles on the Web, thanks both to SEO and general laziness.
Either way, I think all parties can agree on one thing: Apple should at least
include an option to display the full URL for people who really do need to see it
(e.g., Web developers). Happily, that option does indeed exist in the
Advanced section of Safaris preferences. Unhappily, this option does not
allow the address field to get any wider. As discussed earlier, some amount of
empty space in the toolbar is needed to provide a reasonable drag target for
moving the window. The address field does get wider along with the window,
but even with the default flexible spaces removed from the left and right sides
of the toolbar, the address field stubbornly refuses to take up much more than
40 percent of the width as the window expands to fill the screen.
Also, even with the full website address option enabled, favicons are not
visible unless the address field has the input focus. And like other search fields
in Yosemite, the address field center-aligns its contents when it doesnt have
the input focus, but it switches to left-aligned (with an animation) when it gains
focus. This makes for a lot of sliding around and waiting in a field that some
people (e.g., Web developers) use many, many times a day.
Safari 8 has a few more new settings to tweak. Theres now a separate
preference for what Safari should do on startup: open a new window or restore
all windows from the previous session. As in the recent Safari 7.1 update, the
privacy-focused DuckDuckGo joins Google, Yahoo, and Bing as a search engine
choice in Safari 8.
WebGL has graduated from the Developer menu and is now enabled by default.
Allowing webpages to execute code on the GPU presents many new security
challenges. Apple claims to have met these challenges by revising its graphics
drivers to be resilient in the face of malicious or just plain buggy code. Its taken
Apple a long time to get here; WebGL was added to WebKit five years ago. As
with other Safari plug-ins, WebGL can be controlled on a per-website basis. It
can also be disabled entirely in the Security section of Safaris preferences.
[Update: An earlier version of this review stated that Apple had softened its
stance on third-party cookies in Safari 8. This is not the case. The default
Allow from websites I visit setting in Safari 8 behaves the same as the default
setting in Safari 7. Its just differently worded. We apologize for the error.]
Safaris new cookie-handling setting, Allow from current website only, will
only accept cookies whose domains match the sending website. This is
somewhere between the default setting (Allow from websites I visit) and
completely blocking all cookies.
Safaris subtly new cookie preferences.
Private browsing is no longer a mode in Safari. Apple has adopted Googles
approach to this feature, right down to the keyboard shortcut (command-shift-
n), by adding a New Private Window option to the File menu. Private
windows are distinguished by the dark gray background in their address fields.
A new Private Window in Safari. Pity about the explanatory message thats truncated instead of wrapped.
Private windows prevent Safari from recording visited pages, search history,
and text entered into forms. For Safari as a whole, the Clear History and
Website Data option in the History menu now offers several (also Chrome-
like) options to limit the time span of the operation.
Safari adopts another useful feature from Chrome: clear history for a limited time range.
Though I didnt get a chance to test these claims, Apple is touting Safaris ability
to browse the web for two hours longer than Chrome or Firefox on a single
battery charge. Thanks to its native support for Netflix playback (i.e., without
having to install any plugins), Apple claims Safari has a three-hour advantage
over Chrome and Firefox when watching videos from this service.
As usual, the new Safari provides a nice speed bump over the old version. The
most significant new optimization is in the JavaScript engine. Safari 8 uses the
LLVM compiler back end to optimize JavaScript code that has executed
frequently enough to make the compilation time worthwhile. The WebKit
development team has posted a detailed technical overview of this new system,
dubbed the Fourth Tier LLVM JIT, or FTL for short. This, along with the three
preexisting optimization tiers employed by WebKit, highlights just how much
engineering time and effort goes into making a dynamic language like
JavaScript execute quickly. (This will be relevant later.)
Mail
Mail is spared any radical title bar changes. It mostly looks like its old self, save
for the expected translucent sidebar, subtly redesigned toolbar images, and, of
course, all the new standard controls.
Yosemites new placeholder for people with no associated photo in your
Contacts database is a circle containing the persons initials. For example, the
AD in a circle in the screenshot below is short for Apple Developer, the sender
of the selected e-mail. The initials might seem silly, but some information, even
if its not uniquely identifying, is an improvement over a generic silhouette of a
human head.
Yosemite Mail: refreshed, but familiar.
Mail got a bit of a black eye in Mavericks thanks to some bugs that specifically
affected Gmail users. A couple of patches eventually set things (mostly)
straight, but the basic mismatch between the organizing principle of Gmail
(each message may have multiple labels) and Apple Mail (each message resides
in a single folder) remains a source of UI friction.
To burnish Mails reputation, Apple is promoting two new features added in
Yosemite. The first solves one of the longstanding problems with e-mail: widely
varying limits on large attachments. Every e-mail service is different, and there
are often limits on both the sending and receiving ends. Even the most
dedicated follower of the tech industry cant be expected to memorize and track
these limits across all e-mail providers.
Tech-savvy users can easily sidestep the issue by uploading large attachments
to a file-sharing service that provides public URLs, e-mailing those URLs
instead of the attachments themselves. But this is a multi-step process, the start
of which may require some software to be installed. Those of us who have tried
walking someone through this procedure over the phone quickly learn just how
much we take for granted when it comes to such simple workarounds.
Apples solution in Yosemite Mail is close to ideal. The new Mail Drop feature
transparently uploads attachments to an Apple server and sends a text link in
the e-mail instead of the file. From the senders perspective, none of this is
visible. Both the attachment process and the appearance of the attachment in
the e-mail are identical with and without Mail Drop.
Mail Drop itself has some limits, but they are high. Each individual attachment
is limited to 5 GB, and attachment links will only remain active for 30 days.
(The exact link expiration date is displayed in the e-mail.) Mail Drop is enabled
by default for all iCloud e-mail accounts, but it can be used with any e-mail
account.
Conrmation before using Mail Drop with a non-iCloud e-mail account.
If the e-mail recipient is also using Apple Mail on Yosemite, attachments are
downloaded automatically and displayed just as if they had been attached in the
traditional manner, rendering Mail Drop completely invisible to both the
sender and the receiver.
Mail Drop is free, but attachment sending is only exposed through Yosemite
Mail. Its easy to chalk this up to Apples traditional allergy to Web applications,
but Im not sure the world really needs another Web-based e-mail attachment
service. The beauty of Mail Drop lies entirely in its integration with the Mail
application.
The second major feature Apple is promoting as part of Mail in Yosemite is
called Markup. It provides a way to annotate attachments directly within the
message composition window. Any attached image or PDF can be annotated.
(In case youre worried, annotations do not affect the original attachment; a
copy is made behind the scenes.)
The annotation tools are simple but cover many bases: freehand drawing, basic
lines and shapes, formatted and styled text, and camera-scanned or trackpad-
traced digital signatures. The Markup interface is displayed inline, surrounding
the attached image. When annotating an image thats too large to fit within the
message window, a separate floating window appears.
Markup can modify Mail attachments within the message composition window. All Markup strokes are
editable vectors that dont rasterize until the message is sent.
If Markup seems appealing, youll be glad to learn that its actually a system-
wide service based on Yosemites new Extension system; its available in any
application that uses Apples standard text controls. Mail just happens to be an
ideal place to demonstrate its utility.
Finder
As seen in earlier screenshots, the Finder has gotten the standard Yosemite
makeover: translucent sidebar, new-style toolbar buttons, a new application
icon, the works. iCloud Drive (covered later) is the most obvious functional
change. AirDrop (covered later) is also much improved. Theres one more
interesting feature left to cover here.
Its not hard for a programmer to create a quick, incredibly dangerous way to
batch rename files. For everyone else, much safer third-party file-renaming
applications have been around for ages.
This year, Apple has decided that renaming files en masse is an important
enough task that the Finder ought to be able to do it on its own. In the Yosemite
Finders context menu, just below the option to compress selected files (and
just above the increasingly irrelevant option to burn selected files to an optical
disc) is a new Rename option.
The Finders new batch renaming feature is hidden in a context menu.
Note that this command is not available in the Finders main menus; its only in
the context menu, perhaps as a nod toward its fringe appeal. Renaming options
are limited when compared to hand-rolled or third-party options. When
altering file names, the Finder can replace fixed text with other text, add text to
the beginning or end of a file name (before any file name extension), and create
file name sequences using a fixed string prefixed or followed by a number, a
zero-padded counter, or the current date and time.
Finder rename sheet: not many options, but better than nothing.
While most batch-renaming applications provide a comprehensive preview of
the changes before theyre made, the Finder just shows one example filename.
This example is updated in real time as the renaming options are modified.
Luckily, if you make a big renaming mistake, the Finders Undo command will
revert the entire operation.
Contacts
Contacts gets the title-bar-less Yosemite look with the obligatory translucent
sidebar and the new circular contact thumbnail, but it is otherwise mostly the
same as its Mavericks incarnation.
The Contacts application continues to fade away. Can you believe this used to be styled like a
photorealistic leather-bound book?
There are a few new preferences. The preferred short name format can be set to
any combination of first and last names or initials, with a separate setting to
use the nickname field, if present. If you know a lot of Michaels or Jennifers,
this feature will help just as soon as Mac applications start using APIs that
honor this setting, that is. Apples own Messages application will show
nicknames but does not seem to use the short name format in message
windows.
Game Center
The good news is that Game Center has finally shed its wood grain and green
felt textures. The bad news is that the old design has been replaced by the
abstract colored blobs introduced in iOS 7.
As in iOS, the blobs slowly jiggle and stretch. I find myself mesmerized by the
animation, hopelessly trying to discern some meaning or purpose beyond a
designers vague notion that shiny, brightly colored things communicate fun.
I used to point to the parlor games theme of the old Game Center as an example
of Apples lack of respect for and understanding of video game enthusiasts. The
blobs seem even further removed from engagement with gamers. Once again, I
must conclude that this design is not for people like me. Thats fine for now, but
excluding enthusiaststhe people most willing to spend their money on higher-
quality productsis decidedly un-Apple-like. If Apples gaming ambitions ever
extend to the high end, the view of gaming represented by these colored blobs
will need to be revised.
iCloud
As in so many things, Google was ahead of the curve when it introduced the
Chromebook in 2011. It was a product that extended Googles server-centric
ethos to its logical conclusion. All code and data resided in the cloud; the
Chromebook itself was merely a tool for accessing it. As the everyman narrator
in the Chromebooks introduction video asked, I could throw this thing into a
river and not lose my stuff? Google cut the Gordian Knot of PC ownership
hassles by making the hardware disposable.
But as in so many things, being too far ahead of the curve is often
indistinguishable from being on the wrong path entirely. The Chromebook has
not swept away the PC market of yesteryear not yet, anyway. Native
applications still hold sway over the computing world.
Apple has always played yin to Googles yang, pushing native code and
hardware/software integration over Web applications and server-side smarts.
But Apple seems no less convinced of the merits of the Chromebook than
Google. Everything good about the Chromebook is a hallmark of Apples
approach to computing. The core tenet: simplification. The goal: freedom from
worry.
Apple wants to have its cake and eat it, too: fabulous native applications,
powerful hardware, and complete portability of data and identity. But instead
of trying to leapfrog the rest of the industry (as it arguably did with the iPhone),
Apples approach to this problem has been incrementalpainfully so, at times.
This march continues in Yosemite. One feature in particular takes a big step
toward the Chromebook-like goal of having all your stuff everywhere,
independent of any particular hardware device.
iCloud Drive
iCloud-savvy Mac applications have been able to store their documents in the
cloud for years, but as on iOS, each application had its own private location in
iCloud that no other application could see. Furthermore, this location did not
look or behave like a normal location on disk; it was a lot more like
SpringBoard on iOS than a traditional Mac folder, allowing only a single level of
nesting created by dragging one file onto another.
Protecting users from unrestricted file system access has undeniable usability
benefits, as demonstrated by iOS, where this has been the law of the land since
day one. On the Mac, however, adding a new, more limited model for file
storage alongside the existing, traditional model has not been a clean win to say
the least.
While direct interaction with the file system may still be where usability goes to
die, history has shown that all it takes is one good anchor point to make things
at least a bit more comprehensible. In the past, this anchor point was usually
the desktopthe one place people knew how to reliably find. More recently,
Dropbox has filled this role for millions of people.
As of Yosemite (and iOS 8), it appears Apple is finally on board with the single
anchor point idea mostly. Replacing the existing iCloud document storage is
the new iCloud Driveand I do mean replacing. There is a one-time process to
upgrade to iCloud Drive. During the upgrade, all existing iCloud documents are
copied to the new system. After the upgrade, changes made on pre-Yosemite
Macs and pre-iOS 8 devices will not be visible in iCloud Drive. Conversely, any
changes made in iCloud Drive are not visible on pre-Yosemite Macs and pre-
iOS 8 devices. The two storage locations are completely distinct.
Upgrading is not mandatory, but iCloud Drive completely replaces the old
Documents & Data item in the Yosemites iCloud preference pane.
Applications like TextEdit and Preview wont provide access to any form of
iCloud document storage in Yosemite until iCloud Drive is enabled. Youll be
prompted to upgrade during the account setup process. If you decline, you can
upgrade later by enabling iCloud Drive in the iCloud preference pane.
Upgrading to iCloud Drive is a one-time, one-way process.
iCloud Drive is just what it sounds like: a single location for storing documents
in iCloud. All iCloud-enabled applications can see the entire iCloud Drive, and
there is no special limit on the number or depth of folders that can be created
within it.
iCloud Drive even appears in the Finder sidebar just like any other file system
location. But click on it and you may be dissuaded from the notion that iCloud
Drive is a straight Dropbox clone.
iCloud Drive: not quite the same as a simple folder or network drive, but its a lot closer than it used to be.
For starters, the actual location of iCloud Drive in the file system is carefully
hidden. Command-click the window title or use the Finders Get Info command
to try to get a real file path and youll see only iCloud Drive as the top-level
location. You cant even drag the iCloud Drive proxy icon from a Finder
windows title bar into a Terminal window to get a file path. Apple really
doesnt want people knowing where on disk the iCloud Drive data lives.
More weirdness lurks. At the top level of iCloud Drive, badged folders appear
for each iCloud-enabled application. You cant Get Info on these folders either;
the Finder just beeps in protest.
As it turns out, everything is still under ~/Library/Mobile Documents/ in
obscurely named subdirectories, but the careful subterfuge emphasizes Apples
desire to keep iCloud Drive abstract. It is not just a folder that syncs. Its not a
folder at all; its iCloud.
Deleting a file from iCloud Drive presents a warning sheet explaining that the
file will be removed from all synced iCloud devices and put into the local Trash
on this Mac. Moving a file out of iCloud Drive displays a similar warning.
iCloud Drive has a conrmation sheet for every occasion.
These warnings are a good way to remind users that what look like standard file
manipulations in the Finder may actually have far-reaching effects on other
devices. But they also serve to further emphasize the odd nature of iCloud
Drive. Dropbox has gotten by without these kinds of warnings for years. (On
the other hand, this kind of integration with the Finder is much harder for
anyone but Apple to do.)
Rather than adding tiny badges to file icons (as Dropbox does) to indicate the
synchronization status of files in iCloud Drive, the Finder shows the same
progress bars it uses for file downloads from Safari and the Mac App Store.
Propagation times are reasonable, if not lightning-quick. It can take a few
seconds for changes made to iCloud Drive on one Mac to appear on another.
Large files show a small iCloud icon and a progress bar during upload to iCloud
Drive on the origin machine. Only once the file is completely uploaded does it
start to download onto other Macs.
During these uploads, downloads, and brief wait times, theres no global
indication of iCloud Drives state. Is iCloud Drive completely up to date? Is it in
the process of uploading or downloading one or more files? If so, how much
work remains? A menu bar icon like Dropboxs or, at the very least, a spinner
next to iCloud Drive in the Finder sidebar would be nice. These are not esoteric
technical concerns. Knowing when its safe to put a laptop to sleep or leave a
coffee shops Wi-Fi is an important part of any network-based file storage
system.
The drive to succeed
For years, Apple has stubbornly refused to treat iCloud document storage like
just another network drive. Protecting users from direct access to the file
system was a big usability win on iOS, but it was accompanied by a huge
reduction in functionality on the Mac. Optimists assumed Apple would
eventually introduce a new, as-yet-unimagined interface that was as capable as
files and folders but as simple as document management on iOS.
iCloud Drive is not that. Whether its an admission of defeat or a triumphant
return to practicality and sanity is mostly an academic question. What matters
is how much better it makes the lives of Mac users. Given how closely it mimics
Dropbox and other popular cloud storage products (right down to having a Web
interface and Windows support), I think it will be welcomed with open arms
assuming its reliability and performance live up to the standards set by its
competitors.
Family Sharing
Family Sharing, introduced in iOS 8, is a long-overdue acknowledgement of the
way families actually use Apples products. If youve ever had an iPad thrust
into your hands by a child, followed by a plea to enter your password to
complete an App Store transaction, this is the feature for you.
Family Sharing allows purchases to be shared among members of a single
household while still allowing everyone to have their own Apple IDs. Each
family has one organizer and up to five additional members. All purchases by
family members use a single payment method controlled by the organizer. The
organizer and (optionally) any other adult family members can be given the
power to remotely approve purchases made by children.
Dont ever take sides with anyone against the family again. Ever.
Being part of a family provides many more features, including shared photo
streams, calendars, reminders, and location information, all of which are
detailed in our iOS 8 review and in Apples own documentation. There are just
a few additional nuances worth noting.
In the past, Apple did not allow very young children to have their own Apple
IDs. This has obviously changed now. Theres a separate, dedicated interface
for adding an Apple ID for a child, accessible through Family Sharing on
Yosemite and iOS 8. You must be sure to use one of those interfaces, not the
normal (and usually more prominent) adult Apple ID creation interface.
If you were impatient for this feature in years past and have already created
Apple IDs for your very young children using falsified birth years, youre out of
luck. Theres currently no way to convert an existing Apple ID to a child Apple
ID. The best you can do is change the birth years to make your children 13 years
old. (In Yosemite, sign in with a childs Apple ID, go to the iCloud preference
pane, click Account Details, then go to the Security tab.) Youll still be able to
force those accounts to have their purchases approved, but youll have to
remember to adjust their birth years annually to keep them from becoming
adults before their time.
One final warning: an Apple ID can only start or join a family group twice per
year. Presumably this is to prevent frequent family hopping as a means to
quickly and easily share purchases among large groups. But its conceivable
that normal people could run into this limit merely by fumbling through the
setup process. In Yosemite, as in life, think carefully before starting a family.
Extensions
Before the dawn of the OS X age, the entire Macintosh operating system and all
applications shared a single memory space. (Kids, ask your parents about it.)
Any application could seeand modifymemory belonging to any other
application or the operating system itself. The INIT mechanism in classic Mac
OS allowed code to insert itself into the memory image of the operating system
during the boot process.
Though the INIT system started as something limited and undocumented, it
evolved into a popular, officially supported way to extend the functionality of
the OS. Third-party INITs abounded. When System 7 arrived in 1991, INITs
evolved into Extensions, adopting the familiar (to Mac old-timers, anyway)
puzzle piece appearance.
These icons marched across the bottom of the screen from left to right during
system startup. Given the wide-open memory access in classic Mac OS,
Extensions could and did alter the functionality of the Mac in profound ways.
Among a certain set of Mac enthusiasts, it was a point of pride to have many
rows of icons filling the startup screen.
A classic Mac OS startup screen with an extremely unimpressive line of Extension icons.
This was all part of the same thriving culture of Mac customization that
spawned the appearance theme movement mentioned earlier. By the mid 90s,
Macs could be hot-rodded within an inch of their (virtual) livesand beyond.
As you might imagine, having multiple first- and third-party Extensions all
vying to insert their own code into key points in memory was an easy way to
destroy system stability. The exact set of Extensionsand the order they were
loadedcould mean the difference between a functional Mac and one that
didnt even make it through the boot process.
Jeff Robbin may be better known today as the creator of iTunes (ne SoundJam
MP). But to some of us, hes equally revered as the creator of Conflict Catcher, a
classic Mac application whose sole purpose was to manage Extensions and
debug their conflicts by automatically enabling and disabling sets of Extensions
across repeated reboots.
It was the best of times; it was the worst of times. While Mac users cursed the
stability issues caused by classic Mac OSs old-fashioned memory management,
most had one or two favorite system extensions that they did not want to give
up.
When Mac OS X finally arrived in 2001, there was much gnashing of teeth
about all aspects of the new OS, including its vastly reduced capacity for
customization. We all celebrated the stability provided by a modern OS with
memory protection, but that same feature presented a new barrier to the old
style of ham-fisted system customization. Nevertheless, clever Mac developers
found new ways to get their code into other processes, and a new Mac
customization scene started to emerge.
Apple hated this. The transition from classic Mac OS to Mac OS X was long and
painful. Here were these third-party developers recreating the same
unrestricted system of in-memory patching that Apple had just worked so hard
to escape. Popular third-party extensions frequently appeared in the crash logs
of Mac applications of all kinds, as well as the OS itself.
Even today, many of the officially supported extension mechanisms in OS X
work by loading foreign code into the address space of another process. OS X
gives each process its own memory space, of course, so a buggy extension can
only harm the specific process its been loaded into rather than taking down the
entire system (unless its a kernel extension, but those are rare and increasingly
restricted).
Perhaps because of the unavoidable risks of allowing unknown code into other
processes, Apple has not added many officially supported ways to extend OS X
through loadable bundles or similar memory-sharing arrangements. Even
something as common on OS X as a third-party menu bar icon is forced to use a
less capable (but presumably safer) API than the Apple-supplied menu extras.
After three decades, one thing is abundantly clear: people want to customize
their Macs. If Apple doesnt provide a safe way to do so, many people will
choose the unsafe way. This is bad for everyone: Apple, users, and application
developers. In Yosemite, finally, Apple has found a way forward.
Extensions in Yosemite
Offering further proof that Apple is not averse to reusing proper nouns from its
own past, Yosemite supports a new way to add functionality to applications and
the OS itself called Extensions. The name is just about the only thing shared
with classic Mac OS Extensions, however.
For starters, OS X Extensions come bundled with applications; they cannot be
purchased or installed separately. Though they are distributed inside an
applications bundle, Extensions are not just applications launched in a special
mode. They are separate, purpose-built binaries, with their own containers,
code signatures, and entitlements. A single application may include multiple
Extensions.
By default, Extensions dont have privileged access to the data managed by
their containing application. Yosemite adds a new security feature called App
Groups that allows explicit sharing between related applications. Using App
Groups, developers can create a shared storage area that can be used by an
application and its extensions.
Developers must take care to coordinate access to the shared container. Unlike
classic Mac OS Extensions, OS X Extensions do not occupy the same address
space as the application or process they are extending. As you might have
guessed based on the privilege separation described earlier, Extensions run in
their own, separate processes. Even multiple instances of the same Extension
are in separate processes. This means that an application and one or more of its
Extensions may be running simultaneously. Therefore, its imperative that
developers use one of OS Xs file coordination or other mutual exclusion APIs.
Extensions are never launched directly by the user. Apple framework code is
responsible for finding Extensions on the system and launching them in
response to user actions. The system may launch an Extension even when its
containing application is not running.
Extension processes are expected to be short-lived and mostly stateless. The
system is very aggressive about killing Extensions when their work is done,
allowing only a brief opportunity to save any dirty state.
Privacy settings still apply to an entire application bundle as a unit, including
all Extensions contained therein. If the user allows an application to access
Contacts data, for example, all Extensions contained in that applications
bundle will also have access to Contacts data. This policy may seem too broad,
but the alternative is for a dialog box to appear for every Extension within an
application that has already been given the relevant permission. I think Apple
made the right choice.
Extensions bind to Extension Points, which mark the extensible parts of the
system. Yosemite has four Extension Points, and therefore supports four kinds
of Extensions.
Share Extensions allow third parties to add their own applications to OS
Xs pervasive share buttons. Previously, the online services and applications
available as sharing destinations were entirely controlled by Apple and
included only big names like Facebook and Twitter. Share Extensions level
the playing field.
Today Extensions appear in the new Notification Centers Today view.
Apple calls Today Extensions widgets, as if we needed any more hints
about Dashboards eventual demise.
Action Extensions are used to alter content within another application.
The Markup feature that Apple advertises as part of Mail is actually an
Action Extension that can work in any application that includes graphics
and supports the Action Extension Point. (Try adding an image to a
TextEdit document to see an example.)
Finder Sync Extensions allow third-party developers to express file
synchronization status and control within the Finder. This should sound
familiar to Dropbox users accustomed to seeing its icon badges and custom
context menu items in the Finder. Ill give you one guess how Dropbox has
been adding this functionality to the Finder thus far, and one more guess
how Apple feels about it. (Answers: fragile, unsupported, in-memory
patching and hates it!)
Extension Points themselves are implemented in system frameworks. Yosemite
does not support third-party Extension Points, so the four kinds of Extensions
listed above are all youre going to get until Apple adds more (or opens things
up to third parties).
Share Extensions invoked within Safari have the ability to run JavaScript code
within the current page to extract information from the DOM or to modify the
content of the page before the Extension runs.
Action Extensions declare which kinds of data they can handle; they can appear
in any application that deals with one or more of those data types. They can be
used to view content in a new way or to edit content and then return the
modified version back to the host application. An Action Extensions interface
can appear as a modal window or as a custom view directly within the host
application. Action Extensions can even register themselves as being available
as toolbar items, allowing them to appear in the standard Customize
Toolbar sheet for the host application.
The Markup button in Mails toolbar customization sheet is provided by the Markup Action Extension.
A new Extensions preference pane (featuring a puzzle piece icon as a nice echo
of classic Mac OS Extensions) provides a simple interface for enabling and
disabling specific extensions. This is useful even if you never install a third-
party extension, if only as a way to keep unused services out of your Share
menu.
The Extensions preference pane is not much to look at, but it gets the job done.
In OS X, Apple wants developers to think of Extensions as a way to expose a
subset of their applications functionality throughout the system. This is an
appealing concept, but it seems to preclude the creation of Extensions that exist
for their own sake. Will the Mac App Store accept empty stub applications
that only exist as vehicles for the extensions they contain?
The good news is that, technologically speaking, there is nothing preventing
extensions from becoming standalone products if Apple ever decides to allow it.
As noted earlier, Extensions are already completely independent entities that
are merely hitching a ride inside an application bundle. As the number of
available Extension Points expandsas I hope it will in future versions of OS X
Apple may want to reconsider its Extension distribution policies.
Age of Extensions
Back in 2006, at the height of the controversy over Haxies and other
memory-patching system extensions in OS X, I implored Apple to add a clean
mechanism for extending OS X in the handful of ways that were demanded by
the largest number of users. My argument then was that the popularity of
particular Haxies could help Apple decide where to add extension points to OS
X. I drove this point home using a story I first heard from Larry Wall:
When the University of California at Irvine campus was first built, they
just put the buildings in. They did not put in any sidewalks; they just
planted grass. The next year, they came back and built the sidewalks
where the trails were in the grass. Thats what haxies are to the Mac
software market. Haxies are those paths in the grass.
Haxies are long gone, but Apple has finally answered the call for an official
extension mechanism for OS X. In three out of four cases, Apple is putting
down pavement on paths it created itself. Share buttons have existed since OS
X 10.8; Action Extensions are a spiritual successor to Services, which have
existed since the NeXT days; the Today area of Notification Center was just
added by Apple in Yosemite. Only Finder Sync Extensions find their origin in a
popular third-party system extension implemented using dangerous techniques
due to a lack of clean hooks from Apple.
Truth be told, these days I see far fewer unsafe system extensions in use on
Macs, even those owned by the same kinds of technology enthusiasts who
would have souped up their classic Mac OS systems with umpteen Extensions
and appearance themes. Some of this is due to Apples efforts to discourage
unsupported system extensions. As OS X has raced forward in terms of features
and technologies, system extensions have frequently broken. It takes time and
money to keep finding new ways to make these hacks work. Perhaps its just not
a viable market anymore for most developers.
Thankfully, Apples response to its apparent victory in the war against
unsupported hacks has not been to lock the system down further, but to finally
create, for the first time in the Macs history, a safe, supported mechanism for
system extensions.
The new Extensions system is making me give all the existing memory-sharing
extensions in OS X the stinkeye, especially the officially supported ones. Why
should a buggy menu bar icon cause the entire SystemUIServer to crash? I
really hope that Apple plans to replace each legacy extension mechanism with a
new type of Extension Point.
As excited as we Mac users should be about Extensions, at least weve always
had a relatively easy way to use memory-patching extensions. The only option
iOS users have had is to jailbreak and seek out system extensions from the
more shady corners of the Net. Theres good news for everyone this year; iOS 8
also includes support for Extensions.
This is relevant to the Mac because Apple has intentionally made the APIs
similar enough that developers can share a substantial amount of code between
iOS and OS X Extensions of the same type. In a world where there are far more
iOS devices than Macs, every little thing that makes it easier for code written
for an iOS app to be reused on OS X is a good thing for the Mac software
ecosystem.
Continuity
Continuity is Apples umbrella term for its new effort to improve the integration
between Macs and iOS devices. Though Apple has steadfastly insisted that its
dual-OS strategy is the appropriate way to maximize the utility of its Mac and
iOS hardware lines, Continuity is a public acknowledgment that those two
product lines are often used by a single person whose activities are not easily
divided into two neat, non-intersecting silos.
Continuity in Yosemite encompasses several new features and technologies,
most of which require iOS 8 on the other side of the great device divide. With
both OS updates just a few clicks and $0 away, chances are good that at least
one aspect of Continuity will make it tempting to upgrade both sides of your
Apple hardware life simultaneously.
Handoff
Handoff takes aim at the difficulty of transitioning between devices while
continuing to work on the same task. Imagine youre composing an e-mail on
your iPhone as you ride to work on the train. You arrive at the office, but the e-
mail isnt complete. Youd like to sit down at your Mac and finish the e-mail on
your big, comfortable keyboard.
Most people reading this know its possible to save a draft of the outgoing
message on the server and then launch Mail on the Mac, sync with the server,
find the saved draft, and resume typing the message. To fully understand
Handoff, you must accept that Apple thinks this perfectly functional interaction
is not good enough, that it contains too much friction and too many steps.
Assuming youre using a Handoff-capable e-mail application like Apples Mail
on iOS and OS X, heres how the same task could be accomplished. Upon
arriving at your desk in the office, the Apple Mail icon appears in a single-item
mini-dock to the left of the real Dock (or on top, if your Dock is on the side of
the screen).
Items available for Hando! appear in a mini-dock next to the regular Dock.
A similar icon also appears in the command-tab application switcher. Clicking
the icon in the mini-dock or selecting it from the application switcher launches
Mail (if its not already running) and displays a message composition window
containing the exact e-mail message you were just composing on your phone,
with the insertion point in the message area at the end of the text youve written
so far.
This is the kind of thing that wouldnt be out of place in a pie-in-the-sky
concept video from a technology company, but its real and its shipping today.
When all the dots connect, it really is a neat experience. Now lets talk about
those dots.
To start, Handoff is proximity-based; it only functions when two devices are
near each other. So theres no concern that composing an e-mail on your
iPhone while on vacation will cause an icon to appear next to the Dock on your
Mac back at the office. Devices use Bluetooth low energy (BTLE) to discover
each other. If youre not within BTLE range (a few hundred feet, at most),
Handoff is out of the picture.
Handoff works between any combination of iOS devices and Macs (e.g.,
between two Macs or from an iPhone to an iPad) as long as theyre all running
at least iOS 8 or Yosemite and are all logged into the same iCloud account.
Applications must explicitly support Handoff. The two applications involved in
a Handoff do not have to be the same on both devices, but they do need to be
from the same developer. The same developer check is based on Team ID as
determined by examining code signatures, which means only applications sold
through the Mac App Store or signed with a registered Apple Developer ID can
participate in Handoff.
Each Handoff-enabled application must declare a set of Activity Types
representing the high-level tasks that can be handed off between devices. For
example, composing an e-mail is a good Activity Type for an e-mail application,
but typing the subject line of an e-mail is too specific. Activity Types are
identified by strings written in the standard reverse DNS format (e.g.,
com.apple.mail.compose) but also have human-readable names for
display purposes. During use, applications must set the Activity Type based on
what the user is doing at any given moment. The current activity is advertised
to nearby devices via BTLE.
On the receiving end, applications can claim a set of Activity Types they are
capable of continuing. Applications dont have to claim the same activity types
they create. Applications can also advertise Activity Types without claiming
any.
Given these details, restricting Handoff to applications from the same vendor
seems more like a policy decision than a technical limitation. But theres still
more than enough flexibility for a single vendor to create a suite of cooperating
iOS and OS X applications. A large, capable OS X application that passes
different Activity Types to different, smaller, purpose-built iOS applicationsor
vice versais a particularly interesting scenario.
During Handoff, each Activity Type is accompanied by a user info dictionary
describing the activity. While this dictionary can contain numbers, strings,
URLs, and arbitrary data blobs, its expected to be reasonably small and contain
mostly state information rather than data. For Handoff exchanges that require
more than a one-time, one-way transfer of a small amount of data, a
bidirectional network stream can be set up between the two applications using
an optional feature of the Handoff API.
In an interesting twist, Apple also allows Handoff between a native application
and a website. When setting and advertising an Activity Type, an application
can also specify a website URL through which the activity can be continued. If
no native application on a system claims an advertised Activity Type, a Web
browser icon will be shown instead. Clicking it will load the webpage where the
activity can be continued.
(Even Web browsers must be modified to support Handoff. They must claim a
specific Web-browsing Activity Type to be eligible to receive a URL via Handoff.
Safari supports this, but your favorite Web browser may not, at least initially.)
Going in the other direction, native iOS apps can claim associated website
domain names and receive Handoff activities from a Web browser showing a
page on one of those domains. The website itself must also list the Team IDs
and app bundle identifiers of the native applications that are allowed to
continue one of its activities via Handoff. This list is stored on the Web server in
a cryptographically signed JSON file that is periodically downloaded by the
receiving iOS device.
Apple is infamous for its lack of enthusiasm, lets say, for Web applications, so
its somewhat surprising when any new API has a Web component. But so
many native iOS and OS X applications are companions to websites (e.g.,
Facebook, Twitter, even Gmail) that this kind of integration is a natural fit for
Handoff.
Handoff challenges
Theres no question about it, Handoff demos well. But if it hopes to become a
pervasive part of computing on Apple hardware, like iMessage or push
notifications, Handoff will have to overcome several hurdles. The OS version
requirements are mostly just a delay, given how good Apple has gotten at
convincing users to upgrade. But the Mac is a big part of Handoff, and its
adoption numbers, though improving, still lag behind iOS.
Then theres the developer component. Apple can spread a feature like
FaceTime all by itself, but Handoff requires third-party developers to modify
their applications. Because Handoff only works between applications that
belong to a single vendor, it takes at least two modified applications per vendor
to do anything useful.
The final challenge is related to developer adoption. Will Handoff really be a
useful, widely appreciated feature in practice? Will it be worth a developers
time to implement? Much of the appeal of an impressive demo is in the fantasy
of ubiquity. It will be so cool when I can easily transfer whatever Im doing
from my iPhone to my iPad or Mac! If whatever Im doing is modified by
as long as Im doing it in one of the tiny handful of apps that supports
Handoff, the scenario loses a lot of its luster.
Also keep in mind that a Handoff demo conveniently assumes intent. In the real
world, engaging in an activity thats eligible for Handoff while within BTLE
range of another Mac or iOS device does not necessarily indicate an intention to
transfer the task to another device. And yet each nearby device will dutifully
sprout interface elements to make Handoff possible, if desired. Some people
might find this kind of (literal) action at a distance a bit intrusive. If thats the
case, theres a system-wide preference to disable Handoff in the General
preference pane.
SMS in Messages
If you long to see the green message bubbles on your Mac that denote the
shameful use of a legacy SMS/MMS service, then Yosemite is the release for
you.
The telltale green bubbles of SMS messaging nally make their way to your Mac.
The Mac will use your iPhone as a proxy for SMS communication, sending and
receiving non-iMessage text messages through it. Both devices must be signed
in to the same iCloud account, and there is a one-time verification process to
allow a Mac to use a specific iPhone.
Arguably, this complete symmetry of compatibility between SMS, iMessage, OS
X, and iOS devices should have existed from the very start of Apples messaging
service. Well, now it doesor rather, it will when iOS 8.1 is released on October
20th. This feature will not work with any earlier version of iOS 8.
SMS support on the Mac is a small thing, but Apple really does consider it part
of its overall Continuity effort in Yosemite. Continuity is not just about adding
new features like Handoff that form bridges between platforms; its also about
removing any unnecessary differences in capabilities, no matter how minor.
AirDrop
In the same vein as SMS support in Messages, AirDrop now works between iOS
and OS X. It was a bit of an embarrassment for Apple to have an ad-hoc file
transfer protocol called AirDrop on both of its platforms for a year without any
interoperability between the two. Thats one more functional gap filled in
Yosemite.
AirDrop now works between iOS devices and Macs. Also, that dog totally looks like Harrison Ford.
Personal Hotspot
Using a tethered iPhone as the source of Internet access for a Mac is now a lot
easier in Yosemite for the common case of a Mac and an iPhone that are both
logged into the same iCloud account. (Like cross-device SMS, Personal Hotspot
requires iOS 8.1 or later.)
A separate entry in a new Personal Hotspot section of the Wi-Fi menu lists all
available Hotspots on devices using the same iCloud account. Signal strength,
network type (3G, LTE, etc.), and the iPhones battery status are also displayed.
Selecting a Personal Hotspot device does not require a password.
The new Personal Hotspot section in the Wi-Fi menu.
People logged into different iCloud accounts will still see the hotspot, just as
they did pre-Yosemite. It will be listed alongside all the other available Wi-Fi
networks, and a password will be required to use it.
When tethered, Yosemite will make some effort to avoid burning through your
data plans usage limits, delaying nonessential downloads like software updates
and network backups. To help preserve the iPhones battery, the hotspot
connection will be dropped if the Mac becomes idle.
iPhone calls
The final leap in iOS and OS X integration is to allow Macs to be used for the
one task that iOS devices have stubbornly reserved for themselves: making and
receiving phone calls. No, Yosemite doesnt add a SIM card and a cellular radio
to your Mac (though that would be a wonderful idea, Apple). But Yosemite does
allow a Mac to use a nearby iPhones calling capabilities. Once again, the
currently active user on the Mac must be logged into the same iCloud account
as the iPhone.
Incoming calls are displayed as custom notifications with options to accept,
decline, reply with a text message, or set a reminder to call back later. Text
replies are entered directly in the notification alert.
iPhone calling to the faraway Macs.
If the call is accepted, the Macs audio input and output are used. Theres never
a need to touch the phone at all. Outgoing calls work in a similar manner.
An iPhone call in progress.
Calls can be initiated from the Contacts application by clicking on the (slightly
silly) land-line phone handset icon next to the phone number. A Spotlight
search for a contacts name also reveals the same interface directly within the
search results window. The Messages application can initiate real phone calls in
addition to its existing iMessage and FaceTime capabilities. In fact, any text
that looks like a phone number can be called if the application supports Apples
standard data format detection. Just select the phone number and then right-
click to see an iPhone calling option.
Initiate a phone call based on phone numbers found in text. Also works in Safari, Messages, Reminders,
Stickies, etc.
This doesnt just work in applications like TextEdit and Reminders where the
text is editable. It also works in Safari on un-editable text in webpages. In this
case, just selecting the text reveals a pop-up menu, no right-clicking needed.
Initiating a call from within Safari: a slightly di!erent interface for read-only text.
Missed calls are displayed as notifications whose format is based on the
FaceTime notification settings. Clicking on a missed-call notification banner (or
the View button on a notification alert) will call back using the phone.
In practice, this phone calling integration is boring in the best sense of the
word. Aside from matching the iCloud accounts on the phone and the Mac,
theres not much that needs to be configured. When the phone is on the same
Wi-Fi network as the Mac, it is used for incoming and outgoing calls; when its
not, it isnt. And if you dont want to use this feature at all, it can be disabled
entirely in the FaceTime applications preferences on the Mac.
CloudKit
Apples network file storage services and APIs have had a bumpy road these
past few years. The integration of Core Data, an API that long predates iCloud
and was originally created for local storage only, has been particularly
troublesome. Apple improved iCloud Core Data significantly in Mavericks, but
it may have been too little, too late.
Developers who found Apples offerings unviable have long since had to roll
their own solutions for cloud-based data storage and sync. In most cases, these
alternatives have not resembled iCloud Core Data. Furthermore, theyve often
resembled each other in important ways. To understand why, first consider the
design of Apples solution.
Core Data is a framework for managing a set of related objects representing the
information managed by an application. For example, an application for school
enrollment might have objects representing teachers, students, and classrooms,
with the expected relationships between them: one teacher per classroom,
many students per teacher, and so on.
Core Data allows developers to model and manipulate these items and
relationships as objects in memory. The Core Data framework itself is
responsible for both initializing the state of the object graph when the
application is launched and preserving any changes made by the application,
whether on the local disk or across the network in iCloud.
The alternative cloud storage and sync solutions that third-party developers are
choosing or creating on their own tend to do much less. Instead of just
manipulating objects in memory and allowing the framework to handle the
details of persistence, popular iCloud Core Data alternatives often require
developers to write explicit code to initiate data transfer and synchronization.
Aspects of serialization (i.e., converting an object into a data stream suitable for
sending across the network) and the details of conflict resolution are also often
left up to developers.
Why would developers prefer an API that has fewer features and requires them
to write more code? There are two easy answers: predictability and control.
There are few things more frustrating to a programmer than working with
closed-source, third-party code that isnt working as expected. Theres a reason
the word opaque appears in many developer complaints about iCloud Core
Data. Even with iCloud out of the picture entirely, the black-box, well-take-
care-of-everything design of Core Data itself has historically prevented
developers from implementing what they know to be more optimal solutions
for their applications.
Over the years, Apple has worked to alleviate many of the performance
problems and feature deficits cited by developers. Its been enough to tempt
some developers to reconsider Core Data, but the conversion doesnt always
take. It seems that once developers get a taste of a more flexible, less
prescriptive, maybe evengasp!platform-agnostic storage service, its hard to
go back to iCloud Core Data.
Though Apple isnt abandoning iCloud Core Data, it has finally recognized that
bug fixes and performance improvements will never change the essential
nature of the framework. To address the needs of developers who have rejected
iCloud Core Data, Apple has introduced an entirely new framework and
corresponding back-end service: CloudKit.
CloudKit maintains the most important advantage of any iCloud-based API: its
authentication system is based on iCloud accounts, which most OS X users (and
nearly all iOS users) already have and are automatically signed into. CloudKit
also goes a step further, providing an identity service to OS X and iOS
applications even if they dont use any other aspect of CloudKit or iCloud.
This arrangement is the first big difference between CloudKit and iCloud Core
Data. The underlying structures that make CloudKit workuser accounts,
databases, records, etc.are all exposed to the developer as directly
manipulable components. While there are many convenience APIs built on top
of these structures, the individual building blocks themselves also have public
APIs.
Unlike Core Data, CloudKit is a transport API only. There is no support for local
persistence. CloudKit is entirely focused on sending data to and from Apples
servers. CloudKit queries work in the expected database-like manner, returning
lists of records. When querying the server, applications can request only the
changes made since the last connection (based on a change token issued by
the server). If there are any conflicts, its up to the developer to write the code
to resolve them.
If an application wants to work offline, it is responsible for tracking local
changes in a cache, pushing those changes up to the server when a network
connection becomes available again (resolving any conflicts if this fails), and
then fetching the changes since the last connection and applying them locally.
Developers have complete control over this process, with no ambiguity about
when and how data is transferred across the network. Compared to iCloud Core
Data, CloudKit is, in many respects, a more primitive API. All its moving parts
are laid bare, and all actions must be explicitly initiated by code that developers
write. Developers wanted predictability and control; CloudKit provides it in
spades.
But wait, theres more. CloudKit supports both structured data (e.g., database
records) and bulk data (e.g., large files). There are separate public and private
databases. Public data is visible by all users of an application, even if they are
not signed into an iCloud account. (Anonymous access is read-only.)
Privacy is heavily emphasized in CloudKit. Private data is accessible only to the
user that created it. Even the developer of the application cannot access private
data belonging to users. No user information is exposed by default. Any
disclosure must be requested by the application and approved by the user.
If users opt into CloudKits discovery service, they can be found by other users
of the same application by anonymous record ID (as exposed in a public
database) or e-mail address. Theres also a bulk discovery mode to find anyone
in your own Contacts database who also uses this application and has opted
into discoverability.
Arbitrary queries for user accounts are not allowed. There is no way to find all
users with e-mail addresses ending in @apple.com, for example. The
discovery APIs are the only way to get user information.
Finally, to prevent applications from periodically running queries to check for
new or changed information (burning battery power in the process), CloudKit
supports persistent server-side queries called Subscriptions. These queries are
created by applications but are run on Apples servers in response to changes to
the database. Any time some new data matches one of these queries, a push
notification is sent to all interested devices. This notification includes
information about the query that caused it to be sent.
Limits and pricing
Another benefit of using Apples cloud services is that theyre subsidized by all
the other things Apple does to make money. This is how Apple is able to
provide CloudKit for free to all registered OS X and iOS developerswithin
limits. As Apples developer website attempts to explain, CloudKit has separate
limits for storage and data transfers which are further broken down into
assets (i.e., large files) and database records. The limits start small but then
grow for each new user of an application, topping out at 1PB for asset storage,
10TB for database storage, 5TB per day for asset transfers, and 50GB per day
for database transfers.
Now the (potentially) bad news: the literal asterisk and fine print on all of this
reads, If you need more capacity than the limits listed above, contact us." The
charitable interpretation is that Apple doesnt yet know what it will have to
charge to run this service for developers who have enough users and/or usage
to hit the limits of the free service. The more cynical interpretation is that Apple
wants the flexibility to charge whatever it thinks each developer can afford once
an application is so successful that it hits these limits.
A more straightforward, transparent pricing model would go a long way toward
making CloudKit less risky and more attractive to developers. Lets hope Apple
clarifies its intentions in the coming months.
CloudKit outlook
CloudKit isnt just the network data storage API that developers have always
wanted from Apple; apparently its also the API that Apple has always wanted
for itself. Both iCloud Drive and Apples new iCloud photo library service (upon
which the upcoming replacement for iPhoto is being built) were written from
scratch on top of CloudKit. Looking at it another way, if CloudKit doesnt work
well, third-party developers wont be the only ones suffering.
Apples ability to make sure its servers are always available and that they
answer requests in a timely manner is still an open question. As anyone whos
ever gotten an inscrutable error or interminable spinner from an Apple TV
while trying to watch a video from the iTunes Store knows, Apples use of a
network service does not necessarily ensure its reliability or speed.
The most reassuring thing about CloudKit is its design. It looks a lot more like a
well-executed client library for a traditional Web service than a Cocoa API that
just happens to have a network component. Its still far from the cross-
platform, multi-language ideal presented by Microsofts Azure Mobile Services,
but Azure cant hope to compete with the platform integration of CloudKit on
OS X and iOS.
This overview has barely scratched the surface of CloudKit. Although the API
exposes all the knobs and levers rather than hiding everything inside a black
box, those controls connect to some sophisticated machinery. Implementing an
API like this would be a substantial amount of work for any developer, and
thats without even considering the server side of the equation. This is a
powerful counterbalance to any doubts about reliability or pricing. Like all good
frameworks, CloudKit gives developers a huge head start, allowing them to
spend less time on infrastructure and more time on implementing whats
unique about their applications.
Apple itself is betting the future of its own cloud-based services on CloudKit.
iCloud Drive is a good start, but it still lives in the shadow of more mature,
time-tested services like Dropbox. Overall, Im optimistic. Apples cloud
services may finally be on the right track.
Swift
Software development never stands still. But if theres one gravitational force
that holds sway over the entire profession, its that abstraction increases over
time. Progress is not linearthere have been periods of stagnation, great leaps
forward, and plenty of setbacksbut the long-term trend is undeniable.
The first modern programs were written in machine language: sequences of
numbers often written in binary or hexadecimal. Assembly language was a step
up the abstraction ladder, representing data and instructions with symbols
instead of the raw digits of machine code. Languages like Pascal and C divorced
themselves from the details of any specific CPUs instruction set, providing a
hardware-agnostic interface for programmers. Later still, languages like Java
and C# moved away from direct access to memory.
Apple has been around long enough to have spanned much of this history.
Though the original Macintosh, with its industry-defining GUI, was a technical
marvel in 1984, a large portion of its operating system was written in 68k
assembly code. Apples preferred language for application development has
been on a slightly bumpy road toward higher-level languages, moving from
Pascal to C and C++, taking a detour into Java, and finally arriving at Objective-
C.
Moving up the abstraction ladder does not mean the old, less-abstract
languages disappear entirely. Small portions of OS X are still written in
assembly code today. Larger portions are written in C and C++. The top-level
frameworks that application developers use are mostly written in Objective-C.
Its a continuum, with ever-decreasing proportions of programmers and code at
the lower levels. Ask a modern OS X or iOS developer to create a full-featured
GUI application using only assembly language and expect to be laughed out of
the room.
Programming languages and APIs have their own sort of inertia. Once a
community and a powerful set of tools has built up around a language, its hard
to make the next leap forward. This inertia was on my mind back in 2005 when
I warned that Apple was in danger of falling behind the rest of the industry in
terms of programming language abstraction, just as it had once famouslyand
nearly disastrouslyfallen behind with its operating system, fumbling with the
ill-fated Copland project for years with nothing to show for it.
It took the NeXT acquisition and the return of Steve Jobs to finally give Apple a
modern operating system. What would it take to get Apple to move beyond
Objective-C? If Apple didnt start thinking about its next move soon, I worried
that it could find itself in another Copland-like jam by 2010, at which point I
assumed all its competitors would have higher-level programming languages.
The year 2010 came and went and Apple was still flying high, thanks partly to
its success in the mobile market where its low-level language gave it a
performance advantage over its smartphone competitors. I was appropriately
chastened by my overly cautious timeline, but I nevertheless insisted that the
problem remained. Apple needed to do something.
This opinion faced widespreadand predictableopposition from many Apple
developers, both inside and outside the company. But one very important
person at Apple saw an opportunity to advance the state of the art and seized it.
In July of 2010, coincidentally a month after my Copland 2010 revisited article
was published, Chris Lattner, creator of Apples LLVM compiler infrastructure
and then senior manager and architect in Apples Developer Tools Group,
secretly began work on a new programming language.
Four years later, Lattner, now director of Apples Developer Tools Department,
appeared on stage during the WWDC 2014 keynote and shocked thousands of
assembled developersand quite a few Apple employeesby introducing
Apples new programming language for OS X and iOS: Swift.
Like the end of any good mystery, the announcement of Swift shed new light on
past events. Synthesized properties, dot syntax, blocks, automatic reference
counting, collection literalsall these additions to Objective-C over the years
have, unbeknownst to us, traced the outline of a shape lurking just below the
surface. In the case of ARC, it went far beyond appearances; the work was
directly applicable to Swift.
Im not going to take you on a comprehensive tour of Swifts syntax or features.
Apple has published The Swift Programming Language, a free e-book that
describes the language in great detail. Swift has been changing rapidly since it
was announced; the e-book has been revised four times already. Though Apple
makes some application binary compatibility guarantees, it has explicitly
promised not to maintain source compatibility as the language evolves.
What matters most about Swift is spelled out in the first chapter of The Swift
Programming Language. Swift is intended to be the first industrial-quality
systems programming language that is as expressive and enjoyable as a
scripting language. [] Its designed to scale from hello, world to an entire
operating system.
Perhaps this mission statement is so grandioseso preposterous, eventhat
readers are inclined to gloss over it or dismiss it. But its the key to
understanding the design of Swift.
Such great heights
One part of Swifts mission is easy to understand: it must move Apples
development platform to the next rung on the abstraction ladder; it must be a
higher-level language than Objective-C. That means memory safety by default,
ending the era when even the most routine code was one bad pointer
dereference away from scribbling all over memory and crashingor worse,
silently corruptingthe application.
A higher-level language should also enable programmers to accomplish
common tasks with fewer lines of code and less concern about unimportant
details. The code below, which gets an alphabetical list of Apple employees
under the age of 50, might be mistaken for a mutant strain of JavaScript or
Ruby, but its actually Swift.
let ages = [
"Tim": 53, "Angela": 54, "Craig": 44,
"Jony": 47, "Chris": 37, "Michael": 34,
]
let people = sorted(ages.keys, <).filter { ages[$0]! <
50 }
Even given recent advancements like ARC and collection literals, this code
would be substantially longer if written in Objective-Cand the only guarantee
of memory safety would be the programmers skill. The complete absence of
pointers in the code above (and Swifts bounds checking) provides substantially
more safety.
Swift is a convincing high-level language. The basic data types include the
expected varieties of numbers, Unicode-aware strings, arrays, and dictionaries,
all of which have properties and methods, including literals.
if "hello".hasPrefix("he") {
var sillyFour = 5.predecessor()
...
}
Any type can be extended, including the standard types like strings and
numbers. It only takes a handful of lines of code to make an expression like
99.bottlesOfBeer() print the expected song for any integer value. Its even
possible to extend other classes that can be initialized from strings (e.g., a URL
class), enabling code like "http://arstechnica.com".host to parse the
string as a URL and return the host name.
High-level-language programmers should be feeling pretty comfortable by now,
but it gets better. Despite its rich feature set, the Swift language itself is actually
quite minimal. All the basic data types are not part of the language proper.
Theyre part of the Swift standard library that is loaded automatically by the
compilerand the Swift standard library is written in Swift.
All the string and integer literals and variables in the code samples above are
using these basic types defined in the Swift standard library. Theres no
artificial distinction between primitive and object types as there is in Java, for
example. You dont have to ask for the fancy types that support associated
methods and attributes; all Swift types do. From an external perspective, Swift
is much closer to the everything is an object philosophy embodied by
languages like Python and Ruby than it is to Java, let alone a lower-level
language like C or C++.
Still not convinced? When Apple says Swift aims to be as expressive and
enjoyable as a scripting language, its not joking. A text file containing the code
below will run as expected.
#!/usr/bin/swift
println("Are you not entertained!?")
Think fast
Now comes the hard part. At its best, Swift may approach the conciseness and
ease of use of a high-level language like JavaScript, but recall the amount of
work Apple (and others) have put into trying to make JavaScript fast. And yet,
for all their efforts, few would consider trying to write an entire operating
system in JavaScript.
The same features that make high-level languages safer and easier to use also
make them slower. Consider this line of code, which happens to be valid in both
Swift and JavaScript:
var c = a + b // this needs to be fast
CPUs have instructions for adding two numbers together. Integer values in a
low-level language like C must be explicitly declared as such and are stored in
memory in a format the CPU is able to consume without modification. The
reward for this approach is that C integers can be operated on directly by a
CPUs ADD instruction. Said instruction is exactly what a C compiler will
generate in response to some code that adds two integers.
In a language like JavaScript, var c is a valid declaration because JavaScript
variables can contain any type of value: numbers, strings, objects, or nothing at
all. A JavaScript compiler cant just generate a native CPU ADD instruction
based on the code a + b shown above, because it has no idea if the values
contained in the variables a and b are numbers at all.
If the type of value contained in a variable cannot be determined at compile
time, then this determination must be made at runtime. Furthermore, if it turns
out that one of the variables involved does not contain a number, or if the two
variables contain different kinds of numbers (e.g., an integer and a floating
point value), yet more code must execute to coerce the values into compatible
forms.
In JavaScript, even the + operator is up for grabs in the a + b expression. If a
turns out to contain a string value, then the correct implementation of the +
operator is the one that does string concatenation, not numeric addition.
Remember, all this is happening while the program is running. Instead of
executing a single ADD instruction that was generated at compile time, the
JavaScript engine must run dozens, perhaps hundreds, of instructions just to
figure out what its supposed to do.
Swift cannot possibly be an industrial-quality systems programming language
if it takes dozens of CPU cycles to add two variables containing integers. The
obvious solution would be to require every Swift variable, function argument,
and return value to have an explicitly declared type, just as these do in C and
Objective-C. Then the compiler would know exactly what the code a + b is
doing and which + operator to use.
That sounds fine, but in all the Swift code shown so far, there hasnt been a
single declared type. Two years ago, I speculated that full-fledged type
inferencethe ability to deduce the type of a variable without an explicit type
declarationmight come to Objective-C. Instead we got Swift, which leans
heavily on type inference to achieve its goals.
The variables declared in the Swift code below cannot hold values of any type,
as in the equivalent JavaScript. Each Swift variable has a strictly enforced type
that is inferred by the compiler based on the value assigned to it in the
declaration.
var name = "Bob" // String
var cars = 2 // Int
var temp = 88.2 // Double
But theres a wrinkle. Recall that these basic types are not part of the Swift
language; theyre all defined in Swift code in the standard library. So while the
Swift compiler may know the exact type of the cars variable, its still left with a
more fundamental question: what the heck is an Int?
The compiler will process the standard library and compile the code that
implements the Int type, so it knows that Int exists, what methods can be
called on an Int, and so on. But since Int is not part of the Swift language
itself, how can the compiler know whether its safe to feed an Int directly to a
CPUs ADD instruction?
Theres an additional challenge. All of the operations on Int are also defined in
the standard library and written in Swift. Operator overloading is an oft-
maligned language feature, but given how even the most basic types are defined
in a library, and given how literals are automatically inferred to be one of these
types, its absolutely necessary in Swift. Even a simple expression that adds two
integers could not compile if Swift did not support operator overloading.
Revisiting the a + b example, imagine we have variables with an Int type
combined with the + operator, both of which the Swift compiler knows nothing
about until it compiles the standard library. How can this possibly be as fast as
C code adding two integers?
Lets try defining our own Swift function to add two Ints and then pry it apart
to see how it ticks.
func add(a : Int, b : Int) -> Int {
return a + b
}
The swiftc compiler produces the following assembly code for this function
(comments added). (The __TF3add3addFTSiSi_Si label is the name the
compiler generated for the add() function; youll see more of these auto-
generated names later. They look crazy, but dont worry about them.)
__TF3add3addFTSiSi_Si:
pushq %rbp ; standard function prologue
movq %rsp, %rbp ; standard function prologue
addq %rsi, %rdi ; add two 64-bit integers
jo LBB0_2 ; jump to LBB0_2 if the addition
overflowed
movq %rdi, %rax ; put the result in right
register for returning
popq %rbp ; standard function epilogue
retq ; return from the function
LBB0_2:
ud2 ; abort on overflow by raising an invalid
opcode exception
Lo and behold, theres that efficient ADD instruction (in bold). The system
worksbut how? To learn more, well have to look at something between the
Swift source code and the final assembly code. To do that, we need to know a
bit more about how Swift code becomes an executable binary.
The Swift compiler infrastructure is based on LLVM. This is no surprise. LLVM
was quietly introduced to Apples technology stack seven years ago and has
since expanded to become the foundation of its entire development stack, from
compiler to IDE.
The assembly code shown above is for an x86-64 CPU. Generating this
hardware-specific code is the last step performed by an LLVM-based compiler.
Before that, code is generated for a sort of fictional CPUa Low-Level Virtual
Machine. This code, known as LLVM intermediate representation (LLVM IR),
is what the LLVM optimizer works on. The optimization of LLVM IR is
language- and CPU-agnostic; improvements to this optimizer can benefit all
languages and all target CPUs.
Heres the process for compiling code for an x86-64 CPU using clang, Apples
LLVM-based C/C++ and Objective-C compiler:
Instructing swiftc to show the LLVM IR for our Swift add() function doesnt
illuminate much. Youll see a call to llvm.sadd.with.overflow.i64,
which is the LLVM equivalent of the x86-64 addq instruction seen in the
earlier assembly code. We want to know how the compiler makes the leap from
adding two variables of type Int to calling the fast, native 64-bit addition
instruction, whether thats in LLVM IR or in x86-64 machine code.
The Swift compiler introduces another step and another intermediate form into
the compilation process: Swift Intermediate Language (SIL). Heres the process
for compiling Swift code for an x86-64 CPU using swiftc:
Heres the SIL code swiftc generates for our add() function:
// test.add (Swift.Int, Swift.Int) -> Swift.Int
sil @_TF4test3addFTSiSi_Si : $@thin (Int, Int) -> Int
{
bb0(%0 : $Int, %1 : $Int):
debug_value %0 : $Int // let a
debug_value %1 : $Int // let b
// function_ref Swift.+ infix (Swift.Int, Swift.Int)
-> Swift.Int
%4 = function_ref @_TFSsoi1pFTSiSi_Si : $@thin (Int,
Int) -> Int%5
%5 = apply [transparent] %4(%0, %1) : $@thin (Int,
Int) -> Int
return %5 : $Int
}
// Swift.+ infix (Swift.Int, Swift.Int) -> Swift.Int
sil [transparent] @_TFSsoi1pFTSiSi_Si : $@thin (Int,
Int) -> Int
The a + b code in the body of our function has been converted to SIL code
that gets a reference to the function that implements the infix operator for
adding two Ints (you can see its declaration at the bottom), plus a call to that
function on the two values passed to add(). This code also reveals the name of
the Swift standard library: Swift. The Int type from the standard library is
Swift.Int; the addition operator is Swift.+; and so on.
Calling Swift.+ to add two numbers together would be quite slow. The SIL
shown above is the raw SIL. Certain SIL transformations are run by swiftc
even when optimizations are disabled. The canonical SIL generated by
swiftc for just the Swift.+ function is shown below (comments added).
sil public_external [transparent] @_TFSsoi1pFTSiSi_Si
: $@thin
(Int, Int) -> Int {
bb0(%0 : $Int, %1 : $Int):
// Get a reference to the LLVM sadd_with_overflow
intrinsic
%2 = builtin_function_ref "sadd_with_overflow_Word"
: $@thin
(Builtin.Word, Builtin.Word, Builtin.Int1) ->
(Builtin.Word, Builtin.Int1)
// Extract the two integer values from the Int
structures of the args
%3 = struct_extract %0 : $Int, #Int.value
%4 = struct_extract %1 : $Int, #Int.value
// Build the extra 1-bit int argument expected by
sadd_with_overflow
%5 = integer_literal $Builtin.Int1, -1
// Call sadd_with_overflow_Word to add the numbers
%6 = apply %2(%3, %4, %5) : $@thin
(Builtin.Word, Builtin.Int1)
// Extract the result from the tuple returned by
sadd_with_overflow
%7 = tuple_extract %6 : $(Builtin.Word,
Builtin.Int1), 0
%8 = tuple_extract %6 : $(Builtin.Word,
Builtin.Int1), 1
// Handle the case where overflow occurred
cond_fail %8 : $Builtin.Int1
// Otherwise, wrap the result in a Swift.Int
structure and return it
%10 = struct $Int (%7 : $Builtin.Word)
return %10 : $Int
}
I know this code is getting a bit hairy, but hang in there. Were about to get to
the heart of the matter. Note the references to Builtin in the SIL code above.
The sadd_with_overflow_Word function takes two Builtin.Word
arguments (plus a 1-bit boolean). The Builtin.Word values passed to
sadd_with_overflow_Word are extracted from the Int arguments passed
to Swift.+.
Now we can see the rough outline of the bridge between the high-level world of
the Int type and the low-level world of LLVM IR and (eventually) machine
code. Its not turtles all the way down. Inside each Int structure is a
Builtin.Word whose characteristics are sufficiently well-specified that there
is a direct analog in LLVM IR.
The canonical SIL code for our add() function reveals the final piece of the
puzzle. It contains the inlined code for the entire Swift.+ function:
// test.add (Swift.Int, Swift.Int) -> Swift.Int
sil @_TF4test3addFTSiSi_Si : $@thin (Int, Int) -> Int
{
bb0(%0 : $Int, %1 : $Int):
debug_value %0 : $Int // let a
debug_value %1 : $Int // let b
inlined below
%4 = builtin_function_ref "sadd_with_overflow_Word"
: $@thin
(Builtin.Word, Builtin.Int1) // user: %8
...
%12 = struct $Int (%9 : $Builtin.Word)
return %12 : $Int
}
This automatic inlining is controlled by the transparent attribute, which you
might have noticed attached to the Swift.+ function in the earlier code
samples.
Now, finally, we have all the pieces. Builtin is the gateway between Swift and
LLVM IR. The types and functions exposed by Builtin have direct mappings
to types and instructions in LLVM IR. The transparent attribute denotes
functions that are primitive enough that they should always be inlined.
Generating LLVM IR from SIL code that uses Builtin types and calls
Builtin functions is straightforward: Builtin.Word is an LLVM i64 (or an
i32 when targeting a 32-bit architecture; SIL is more target-independent than
LLVM IR); sadd_with_overflow_Word is the
llvm.sadd.with.overflow.i64 intrinsic function, and so on.
This exploration has revealed something else. The Swift standard library
actually is a little special (beyond just being loaded by default). Though it is
indeed written in Swift, the standard library is the only thing that has access to
the world of Builtin functions and types. It also uses the transparent
attribute to mark certain functions for automatic inlining.
Since the source code for the Swift standard library is not public, we had to
discover these things by examining the SIL generated from our Swift code. But
rest assured, Builtin and transparent are part of Swift itself, not just SIL.
Running strings on the swiftc binary buried inside the Xcode 6 application
bundle exposes a -parse-stdlib option that will compile Swift code under
the same rules as the standard library, allowing the use of Builtin types and
functions. Similarly, adding a @transparent attribute to a Swift function will
ask for it to be inlined.
All these features are undocumented and are confined to the Swift standard
library for a reason. They are not part of the public face of Swift, but they are
necessary for the language to achieve its goals. Builtin in particular provides
an essential connection between the high-level world of Swift types and the
low-level world of LLVM IR. If the Swift standard library does its job well,
developers writing Swift code can be blissfully unaware of the techniques it uses
to ensure speed and efficiency.
Whither SIL?
Its worth considering why SIL exists at all. Though our simple integer addition
example doesnt demonstrate it, there are new kinds of language-specific, high-
level optimizations that can only be done on a representation that retains more
information than LLVM IR does about the source language.
Consider this Swift code, which uses the languages support for generics:
func identity<T>(x : T) -> T { return x }
func testInt() -> Int { return identity(42) }
func testDouble() -> Double { return identity(42.0) }
Generating SIL for this code with optimizations disabled produces a generic
identity() function and separate testInt() and testDouble()
functions that call it. With optimizations enabled, the SIL code contains
specialized (and much shorter) implementations of testInt() and
testDouble() that do not call through to the identity() function at all.
This is the kind of optimization that any decent compiler for a language that
supports generics would be expected to perform. Its also the kind of
optimization that would be awkward or impossible in LLVM IR.
Unlike LLVM IR, only a single language is currently converted to SIL as part of
its compilation process. Its right there in the name: Swift Intermediate
Language. SIL code looks a lot more like Swift than LLVM IR looks like C or
C++, going so far as to import the same libraries using the same names as Swift
code. SIL is sort of a High-Level Virtual Machine (no, not that one or that
one), but its not designed to be a target for other languages. (Unlike the JVM
and CLR, SIL exposes ARC operations and therefore is not memory safe.)
As noted earlier, Apple has specifically stated that Swifts syntax will change in
the future. (Apple is likely to provide automated translation tools to convert old
Swift code to the new syntax.) SIL provides a way to apply Swift-specific
optimizations without adding unnecessary coupling between Swifts syntax and
the generation of LLVM IR. (Clang, which compiles C-based languages with
substantially more stable syntaxes, generates LLVM IR directly from the AST.)
Despite the obvious benefits of SIL in its current role, a syntax-independent,
high-level intermediate form with its own optimizer definitely seems like a
technology with some potential. Its possible that the larger purpose of SIL has
not yet been revealed.
Frameworks integration
Swift may be an all-new language, but Apple has made sure it works with
existing OS X and iOS frameworks. Theres a free e-book on this topic, too:
Using Swift with Cocoa and Objective-C. Apples existing frameworks are
written in C, C++, and Objective-Clanguages that have pointers and direct
access to memory.
Through a series of clever conventions (plus the use of Swift features like in-out
parameters), most Objective-C APIs can be used directly from Swift code
without dealing with pointers. Various Swift data types are also interchangeable
with their Cocoa equivalents. Xcode auto-generates the appropriate header files
so that Objective-C code can access Swift libraries. Apple even provides Swift
translations of Objective-C API documentation.
Conventions and translation cant cover everything, however, especially when it
comes to lower-level C and C++ APIs. To support integration at this level, Swift
does indeed support direct memory access through a family of pointer data
types (with appropriately scary names like UnsafePointer and
COpaquePointer). This is a necessary compromise, and one shared by other
memory-safe-by-default languages like C#.
Swift is too newand was kept too secretto have any major Swift-native
frameworks or applications shipping in Yosemite, but Apples plans clearly
point in that direction. While an application written in Swift may not seem any
different to the user, a framework written in Swiftwith Swifts language
conventions and features in mindmay look very different than even the most
modern of todays Objective-C frameworks. This is the world Apple is building
toward, but it will be a long transition.
The shape of the future
Most people think of programming language design as an exercise in deciding
what developers have to type to accomplish their goals. Debates may rage about
features, semantics, security, and syntax, but the finished product is a language
specificationor, at the very least, some reference documentation. This is what
developers will judge. Is the language too verbose? Are the semantics difficult
to understand? Are there too many weird corner cases? Too many funny
characters? Are some features too complex for their own good?
You can find debates like this about Swift all over the Net, many focusing on
features that werent even mentioned here, like optionals and access control.
Arguing about programming language syntax and semantics is a familiar,
comfortable pastime for developers. Language designers might reasonably
focus on these same concerns when creating a new language.
Swift is a little different. Yes, it was designed to be a language that
programmers will find more productive and enjoyable than Objective-C. It was
designed to provide important safety guarantees while remaining flexible and
extensible. But Swift is also a language created by a compiler engineer.
The design of Swift did not start and stop at the things programmers have to
type. It extends from the syntax all the way down to the machine code. Features
were judged not just by the experience they provide to programmers, but also
by the possibilities they enable or preclude in the compilation process. Swift is
not an academic exercise. Its not designed to be semantically pure or
mathematically elegant. Swift is a language designed with its implementation in
mind from day one.
This approach is not just a side effect of the personality, values, and skills of its
creator. A focus on implementation is a necessary consequence of Swifts
declared mission: to be as fun and expressive as a scripting language while also
being as fast and efficient as a low-level systems programming language.
Swift is an attempt to create a low-level language with high-level syntax and
semantics. It tackles the myth of the Sufficiently Smart Compiler by signing up
to create that compiler as part of the language design process.
The primary tool for ensuring Swifts speed is static analysisa technique with
which the design team has some prior experience. From type inference, which
frees developers from manually annotating every variable declaration, to the
multiple optimization passes done at the SIL and LLVM IR levels, the Swift
language is made possible by the compilers ability to reason about the code
without executing it.
Swifts technique of lashing the most important parts of its standard library
directly to LLVM IR primitives (via the Builtin module) reveals the extent to
which the language and its compilation environment are intertwined. Without
these massive, invisible bolts screwing Swifts basic types to the bedrock of
LLVM (and, ultimately, to machine code), performance could not come close to
that of C or Objective-C.
In some ways, this aspect of Swifts design is akin to the zero-cost
abstractions philosophy of C++. The difference is that Swift confines these
low-level interactions to the standard library instead of exposing the guts of the
system to all programmers.
Beyond its implementation, the developer-facing aspects of Swift do embody a
specific philosophy about software development. Ive been writing software
professionally for 18 years, and I definitely have my own opinions about
language design. For example, I find any coding done in service of the type
system to be mostly wasted effort when writing high-level code that controls
things like which window appears when a certain button is pressed or which
data is fetched from or stored into a database.
Swifts type inference alleviates some of this pain, but it doesnt change the
inherent static typing of the language. The choice between static and dynamic
typing is not just based on the effects each approach has on compiler
implementation. Its alsoperhaps even primarilya philosophical choice
about what constitutes good code.
Motivations aside, its the practical consequences of Swifts design philosophy
that make it resilient to my complaints. I admire Swifts ambitious mission and
I understand how essential each one of its features is to achieving it.
The strongest arguments against Swift are ultimately questions about that
mission. Swift could be a much friendlier high-level language if it gave up on
being an industrial-quality systems programming language. On the other side
of the coin, Swift could be vastly simpler if it focused exclusively on being just
a better C. Few languages have even attempted to do what Swift is doing. The
degree of difficulty is high and self-imposedin other words, a typical Apple
move.
If this were an Apple keynote presentation, now is when Tim Cook might come
back on stage and explain that only Apple could create something like Swift.
While that would be a bit of an exaggeration (witness C# and the CLR from
Microsoft), a project like Swift is an excellent fit for both Apples ambition and
its longstanding tradition of vertical integration.
Its not a stretch to imagine that Apples plans for Swift extend from the source
code all the way down to not just the machine code generated by the compiler
but also the design of the CPU itself. At various times in the past, specific
hardware features of PowerPC, x86, and ARM processors have influenced the
efficiency of fundamental aspects of Apples platform, from function calling
conventions to features of the Objective-C runtime. I would be surprised if
Apple hasnt already lobbied for (or directly implemented, in the case of its own
chip designs) CPU features that are tied directly to its compiler, language, and
runtime stack. I expect even more of this in the future.
Unlike Clang and LLVM, the Swift-specific parts of the compiler toolchain are
not open source. Apple has the resources and influence to ensure the success of
Swift even if it is the only company using it at scale (cf. Objective-C).
Nevertheless, powerful factions within the company are undoubtedly in favor of
making Swift an open source project. The push to release Yosemite and iOS 8
has likely taken precedence so far, but I expect this issue to be revisited.
Swift is the most important change to Apples development platform since the
switch from PowerPC to Intel processors. Despite the expected grumbling from
experienced Objective-C programmers, it is not a lateral move. Swift is a
significant step up in terms of safety, expressiveness, features, and perhaps
even performance, all in its 1.0 release.
Swift is still very young, but it has a bright future ahead of it. If it succeeds, it
has the potential to spread to every corner of Apples technology stack, from
server-side programming to installer scriptsmaybe even to the Web. But
Swifts role as the successor to Objective-C is important enough on its own. In a
way that all past enhancements to Objective-C have not, Swift has the potential
to ensure the viability of Apples development platform for decades to come.
Grab bag
When it comes to finding new details in the nooks and crannies of OS X,
Yosemites sweeping graphical update is the gift that keeps on giving. Even after
months of using Yosemite, Im still routinely surprised by a new icon, cursor, or
interface layout. There are plenty of minor functional changes as well. Here are
a few favorites.
Activity Monitor
Earlier versions of Activity Monitor required a tedious mouse-over-and-wait
action to see the URL associated with a Safari back-end process. The new
Activity Monitor in Yosemite helpfully shows the URL in place of the unhelpful
Safari Web Content process name.
Its now much easier to use Activity Monitor to nd and kill the process behind a misbehaving Safari tab.
Terminal
While third-party alternatives like iTerm still offer many more features, the
sturdy, dependable OS X Terminal application has always met my needs. Its
also an application that has, at times, had less than one whole Apple developer
dedicated to it. These days, any change at all is noteworthy. The most visible
addition in Yosemite is an in-window scrollback search interface that replaces
the old, awkward dialog box.
Terminals new inline search eld. Our babys all grown up
Messages
In another refreshing instance of platform parity, Yosemites Messages
application includes audio message support (click the microphone button to the
right of the text input field) plus the ability to mute or leave a group chat. New
participants can also be added to an existing group chat. If one or more people
are sharing their location information with you, a map will appear in the
Details popover with each persons avatar correctly placed. Thumbnails of
images sent as part of the conversation are collected at the bottom of the
popover.
New group chat features lurk under a popover spawned from a decidedly iOS-like borderless button in
Messages.
JavaScript automation
Its been a while since the open part of Apples Open Scripting Architecture
has been meaningfully exploited; AppleScript is the only OSA language most
Mac users know (if they know any at all). In Yosemite, Apple has stepped up to
the plate and added a JavaScript OSA front-end based on WebKits
JavaScriptCore engine. As a cherry on top, theres a built-in Objective-C bridge,
opening up the world of Cocoa and even plain old C to your humble JavaScript
code.
Remember, the application is called Script Editor, not AppleScript Editor.
System Preferences
Like the rest of Yosemite, System Preferences has received a nearly complete
visual overhaul. The new preference pane icons are not quite as immediately
appealing as the best of the new application icons, but they are pleasant
enough.
Notifications is the most changed, but Im not sure it evokes its namesake any
better than the old icon. Energy Saver has been upgraded from a CFL bulb to an
LED. Apple still doesnt quite know what to do with the General icon, but at
least it looks familiar. The Date & Time icon is new, but the date still never
changes from the 18th. (At least we now know what month its frozen in: July.)
The Startup Disk icon still depicts a spinning hard disk despite the increasing
prevalence of solid-state drives. Either way, its always been strange that Apple
has chosen to use an image of a part from inside its computers as an interface
icon. Like the floppy-disk save icon, this bit of mechanical history may be with
us for a while yet.
The newly combined title bar and toolbar now includes back/forward buttons.
A grid of tiny dots replaces the Show All button text. Navigating with these
three controls means passing back through the main screen each time you want
to open a new preference pane. The back/forward buttons dutifully replay this
history, with every other step showing the full set of preference panes. Moving
directly from one preference pane to another using the View menu produces a
more sensible navigation history, but who does that? Im not sure how many
people even know that menu exists.
If Apple wants to improve preference pane navigation, Id much prefer a
customizable toolbar that would let me add buttons for my most frequently
used preference panes.
General
The new dark mode and Handoff checkboxes were mentioned earlier, but
theres one more change worth mentioning. The default Web browser is now
selected here instead of in Safaris own preferences.
Desktop & Screen Saver
A nice collection of photos from Yosemite National Park are included for your
desktop viewing pleasure. In exchange, we have lost the hard-won setting to
disable menu bar translucency, and the underlying property list setting no
longer seems to be honored. If you dont care to see whats behind your menu
bar, going fully opaque may be your only option.
New pictures of Yosemite National Park, but no more translucent menu bar toggle.
Mission Control
As if we needed any more hints that Dashboard is not long for this world, the
mission control preference pane now includes an option to turn Dashboard off
entirely.
The future is not bright for Dashboard.
Security & Privacy
Theres a new setting in the Diagnostics & Usage section to control whether this
information is shared with third-party developers in addition to Apple itself.
Both options are checked by default.
You get a crash report! You get a crash report! Everybody gets a crash report!
The Location Services privacy list now covers System Services (currently just
Spotlight Suggestions). Theres also a separate option, disabled by default, to
display the location services menu bar icon when system services request
location information.
Options for the use of Location Services by parts of the operating system itself.
Notifications
When Do Not Disturb mode is engaged, Yosemite no longer offers the option to
allow FaceTime calls from your favorite people only; its everyone or no one.
The customization options available in the newly redesigned Notification
Center replace the old setting to enable and disable Share Buttons in the
Notification Center sidebar.
App Store
Theres a new option to install OS X updates automatically. Like the similar
option for application updates, automatic OS updates are disabled by default.
But something tells me its only a matter of time before both of those defaults
are reversed.
The new option to install OS updates automatically is not on by default for now.
Recommendations
Like iOS 7 before it, Yosemite is an aesthetic one-way valve. Though the new
appearance is not particularly radical, its so comprehensive that it quickly
establishes itself as the new normal. Switching back to Mavericks after a week
or two in Yosemite is like returning to iOS 6. Everything looks embarrassingly
chunky, glossy, and gaudy. This will likely be true even if you have reservations
about the wisdom of using onionskin as a building block for a user interface.
The visual changes are also why Yosemite may feel like a more significant
upgrade than Mavericks. For people who value being on the cutting edge of
both fashion and technology, this will make Yosemite more attractive. For
others, it will inspire some additional upgrade caution. Among the biggest
curmudgeons, Mavericks may even become the new Snow Leopard: the last
good release before Apple ruined everything.
In truth, Yosemites new look is not a signifier of any particular fitness (or lack
thereof) for upgrade purposes. The standard rules apply. Dont upgrade until all
the applications you care about are compatible. Make sure you have good
backups. Point-zero releases are always a little more risky. Wait for version
10.10.1 if youre nervous.
Ive been upgrading all my Macs sooner after each OS X release for the past
several years and have not regretted it. When it comes to stability, it feels like
Apple is really hitting its stride with these yearly releases. Mavericks has been
very solid for me. Im optimistic about the long-term stability and compatibility
prospects for Yosemite. As for bugs like the Mavericks Gmail problems, I have
some hope that the public beta program has helped root them out before
release.
My concerns about scope remain. Yearly releases add administrative overhead,
delaying features that take more than one release cycle to developsome of
which are already overdue. That said, Yosemites new look was one such
overdue change. I would not have wanted to wait any longer for it.
The mobile market continues to evolve much faster than the more mature PC
market, providing ample motivation for iOS to continue on its aggressive
schedule. With Yosemite, being in sync with the yearly iOS releases has become
a lot more important.
One will, one resolve, one cause
The historic lack of integration between iOS and OS X is shocking in retrospect.
The interaction concepts and visual treatments that did migrate from iOS to OS
X tended to arrive as invasive species. Some technologybut precious few ideas
moved in the opposite direction. Apple had let the dysfunction of its org chart
leak through to its customers, and the results were not pretty.
Then came the reorganization, with its promise to increase collaboration
between groups.
The signs were all good, but it takes a long time to turn a ship as big as Apple.
Mavericks was released in the middle of this course correction, remaining
uncomfortably out of step with iOS.
Yosemite and iOS 8 are the first great victories for the newly collaborative
Apple. The visual coherence between the products blessedly obsoletes the
former one-way mimicry and reflects a deeper technological unity. Features like
Handoff that require cooperation in all stages of development, from
conceptualization to execution, are evidence of an Apple that puts the needs of
its customers ahead of departmental divisions.
The political and technical battles inherent in the former two-track
development strategy for OS X and iOS left both products with uncomfortable
feature disparities. Apple now correctly views this as damage and has set forth
to repair it. New features like Extensions share as much technology as possible
and appear on both platforms simultaneously.
Extensions are also a sign that old prejudices have departed with the old
leadership regime. Once seen as a wart on OS X that iOS was lucky to be
without, customization is now deemed important enough to be possible on both
platformssafely. The list of Things Apple Will Never Do is slowly being
replaced by the list of Things Apple Has Done.
Then theres iCloud, the one offering that cant help but be shared among
Apples platforms. Even here, the perceived stubbornness of the past has been
lifted. CloudKit is Apples acknowledgment that its previous offerings did not
meet the needs of developers. The extensive use of CloudKit in Apples own
products reinforces the notion that this is not a grudgingly offered concession
but a true change of heart.
The distinct Dropbox flavor of iCloud Drive is another reversal of a
longstanding policy. Copying the feature set and interface of the market leader
is not a comfortable position for Apple, but sticking with a less-capable, less-
popular alternative was worse for everyone involved. Apple has shown that it
wants to succeed more than it fears being seen as a follower.
Viewed in isolation, Yosemite provides a graphical refresh accompanied by a
few interesting features and several new technologies whose benefits are mostly
speculative, depending heavily on how eagerly theyre adopted by third-party
developers. But Apple no longer views the Mac in isolation, and neither should
you. OS X is finally a full-fledged peer to iOS; all aspects of sibling rivalry have
been banished.
The Mac today is just one part of a conceptually, organizationally, and
(increasingly) technologically unified platform that spans from wrist to
workstation. The hardware-based platforms of the past remain relevant to
developers, but Apple seems determined to make them much less important to
its customers. With Yosemite, the Mac has taken its first step into a larger
world.

OS X 10.10 Yosemite Review

Hochgeladen von

Dokumentinformationen

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

OS X 10.10 Yosemite Review

Hochgeladen von

Copyright:

Verfügbare Formate

17/10/14 21:49 OS X 10.

10 Yosemite: The Ars Technica Review | Ars Technica

Das könnte Ihnen auch gefallen