Apple has updated Mac OS X Lion to version 10.7.1, fixing only a small number of important bugs and revealing that the recently released MacBook Air and Mac mini models were on a slightly different development track, since they get their own updates.
Should you update? Apple’s recent woes with minor Mac OS X updates lead me to suggest that it might be worth waiting a few days, but this update is so focused that the chance that it would introduce significant new problems seems low. As always, we recommend you have a solid backup in place before proceeding with a system update until such time as Apple allows us to roll-back from a problematic update.
Mac OS X 10.7.1 -- With OS X Lion Update 10.7.1 (Client), Apple calls out only five specific fixes, and while there are undoubtedly a few others, the update is small — only 17.4 MB via Software Update for me, and 79.29 MB from Apple’s site — implying that it really is a focused update. The fixes:
“Address an issue that may cause the system to become unresponsive when playing a video in Safari.” Although Apple’s description makes no reference to the significant video freezes that users of recent iMacs have encountered under Lion, both Kirk McElhearn and Michael Cohen tell me that they haven’t experienced any freezes since upgrading to 10.7.1 (see “Video Viewing in Lion Freezes New iMacs,” 4 August 2011). So perhaps this bug has been eliminated!
“Resolve an issue that may cause system audio to stop working when using HDMI or optical audio out.” This sounds remarkably like the fix in the Mac OS X 10.6.8 Supplemental Update that was necessary to resolve the audio problems introduced in the move from 10.6.7 to 10.6.8. Apple described that bug as “System audio that stops working when using HDMI or optical audio out.”
“Improve the reliability of Wi-Fi connections.” This has been a major problem for Lion users, to the point where there are several lengthy complaint threads in the Apple Support Communities, one with over 500 comments and another with nearly 400 comments. Hopefully 10.7.1 does indeed resolve the problem — some of the discussions suggest that the combination of updating to 10.7.1 and resetting the PRAM and SMC may be efficacious.
“Resolve an issue that prevents transfer of your data, settings, and compatible applications to a new Mac running OS X Lion.” Wait, we’ve heard this before too, with the Migration Assistant updates that Apple has released for both 10.6 Snow Leopard and 10.5 Leopard.
“Resolve an issue in which an admin user account could be missing after upgrading to OS X Lion.” Oddly, this fix is listed only on the About page for 10.7.1, not on the download page for the update or in Software Update. Definitely a good bug to address, though.
If you have one of the just-released MacBook Air or Mac mini models, there’s a different update for you, the OS X Lion 10.7.1 Update for MacBook Air and Mac mini 2011 (Client) (68.86 MB). Along with the previously mentioned fixes, it includes fixes that:
“Resolve an issue where MacBook Air may boot up when MagSafe Adapter is attached.”
“Resolve an issue causing intermittent display flickering on MacBook Air.”
“Resolve an issue that causes the SD card slot in Mac mini to run at reduced speed with SD and SDHC media.”
Hopefully, with 10.7.2, the new MacBook Air and Mac mini will be brought back into the fold so we won’t have separate updates to track.
Mac OS X Server 10.7.1 -- The OS X Lion Update 10.7.1 (Server), which is an 88.26 MB download, addresses exactly the same five bugs, with only one additional change called out on its About page — improvements in the reliability of the Apple File Service.
And, since Apple sells a Mac OS X Server configuration of the new Mac mini and you can install Mac OS X Server on a new MacBook Air (though that seems like an unusual action to take), there’s a special update for these machines as well, the OS X Lion 10.7.1 Update for Mac mini 2011 (Server). It’s 78.11 MB, and includes the same MacBook Air and Mac mini fixes as the client version of 10.7.1.
Waiting for 10.7.2 -- As with the 10.6.1 update to Snow Leopard, 10.7.1 is so small that it seems clear that Apple is using it to stamp out just the most egregious bugs (see “Tiny Mac OS X 10.6.1 Update Fixes Some Bugs,” 10 September 2009). The question is, then, when we’ll see 10.7.2, and if it will go beyond fixing major bugs to address more minor concerns and changes that, while not actually bugs, seem counter-productive.
Read and post comments about this article | Tweet this article
One of the most frustrating aspects of iTunes is the way you can end up with multiple libraries — one on your iMac at work, one on your MacBook Pro, one on your spouse’s MacBook — all with slightly different contents. And while you could of course move the necessary files from one computer to another, doing so is a major hassle.
The solution to this problem is SuperSync, from the company of the same name, which can synchronize two or more iTunes libraries on networked computers — across a LAN or the Internet. It can also read music from a folder that contains music, or that is referenced in an iTunes Music Library XML file, but most interesting is SuperSync’s capability to read music from an iPod or iOS device (so you could, for instance, move your music from your iPhone to your Mac at work, even though you sync your iPhone with your Mac at home).
When syncing between two iTunes libraries, SuperSync moves the media files, updates iTunes, and even updates metadata like play counts, ratings, and so on. The fact that you can do it bidirectionally means that you don’t have to worry about changes on one Mac being overwritten by changes on another. SuperSync even works under Windows, if you want to sync your Mac’s music with your Windows machine at work. Other useful features include the capability to find duplicate tracks and corrupt files and listen to your entire music library over the Web. SuperSync costs $35 for use on up to five computers and an unlimited number of iOS devices.
Read and post comments about this article | Tweet this article
Every release of iOS comes with a healthy share of new features, updates, tweaks, and the inevitable accusation that Apple is up to no good.
Case in point, TechCrunch broke the news last week that the latest beta of iOS 5 begins to phase out developer functionality that can be used to track individual devices.
The rest of the Mac punditry machine quickly piled on, accusing Apple of trying to shut competitors out of the iPhone market and claiming that developers will no longer be able to provide users with services like scoreboards, personalized accounts, and goodness knows what else.
There seems to be general agreement, therefore, that this change (which Apple, true to form, made in the latest beta with little fanfare) is a Big Deal. There’s also a lot of confusion, however, on exactly what a UDID is, what it does, and why it is being discontinued.
UDID, What Art Thou? -- The term “UDID” is an acronym that stands for “Unique Device IDentifier.” It’s a unique 160-bit number that is calculated by iOS based on several hardware characteristics of a device; as its name implies, each iPhone, iPad, and iPod touch has its own UDID.
Apple uses UDIDs for a number of different purposes, including sending push notifications, managing ad-hoc provisioning (which is used by registered developers and enterprise users to distribute apps outside of the App Store), and so on.
Until now, the UDID has also been available to developers, who have traditionally used it whenever it has been necessary to track individual devices — for example, to provide scoreboards, or offer additional personalized services.
There is nothing wrong with this: the UDID is not a secret and cannot be used to steal any information from the user. In fact, Apple even provides a helpful support article that explains how you can find a whole alphabet soup of identifiers associated with your device.
Unfortunately, the fact that the UDID is available to every app without the user’s consent has led to an unexpected consequence: third parties, like ad networks, have been able to use it to track usage across multiple apps, thus breaking a primary tenet of iOS, that apps run in complete isolation from one another, in part to protect the user’s privacy.
Given how steadfastly Apple has defended this feature of its mobile operating system in the past, and the fact that the company has already been sued for “allowing” apps to provide information to advertisers, the fact that UDIDs are going the way of the dodo shouldn’t come as a big surprise.
What Is Apple Doing? -- In hindsight, in fact, Apple’s response to this problem has clearly been in the works for a long time. Over the past few years, the company has rolled out several services that aim at providing developers with alternatives to the types of features most likely to depend on UDIDs, like scoreboards and network gaming (Game Center), ads (iAds), and so on.
Apple is now preparing for the final strike: removing access to UDIDs to thwart those parties that have happily worked around iOS’s privacy model.
Because of the potential impact on so many developers, however, Apple is going about making this change in a deliberate manner. Contrary to several reports that have found their way on to the Web, Apple hasn’t “killed” developer access to UDIDs. Rather, they have simply “deprecated” the functionality, advising developers that it’s likely that it will be removed from a future version of the operating system. To put things in perspective, Mac OS X 10.7 still includes functionality that has been deprecated since 10.2 (although my feeling is that Apple will move much more quickly in this case).
In the immediate future, therefore, nothing has changed. UDIDs are still available to developers, and apps that depend on them will continue to function without problems.
What Happens when UDIDs Disappear? -- Think of this initial move as a call to action. Apple is telling developers that it will, sooner or later, make developer access to UDIDs go away.
Those who have needed access to UDIDs for reasons that Apple sees as legitimate are likely in for some work converting their apps to the appropriate technology provided by iOS, but should otherwise have no problem providing their users with uninterrupted service and no loss of data. As a bonus, the user experience connected with these services will be uniform, resulting in fewer headaches for both users and developers.
Interestingly, even those companies that make “inappropriate” use of UDIDs are unlikely to find themselves completely in the lurch. Since there are several well-established ways of identifying any device connected to the Internet, these developers should be able to continue offering their services without having to depend on an Apple-provided identifier.
Why the change, then? I think it likely stems from two desires on Apple’s part. The first is that UDIDs are highly specific: barring a mistake in Apple’s manufacturing process, these identifiers are guaranteed to be unique — unlike the information that can be gathered through the other methods that I mentioned above. Apple is likely worried about both the perceptual and legal liability of tacitly enabling apps that track users without user-granted permission.
This also leads to Apple’s second desire: Apple wants to tout iOS as the most secure and privacy-conscious mobile operating system on the market, bar none. If developer access to UDIDs enables app usage to be tracked without user knowledge, it’s that much more difficult for Apple to make that claim.
Finally, there is a third possibility: that Apple is, in fact, trying to block third parties from encroaching on the businesses that it intends to create around technologies like Game Center and iAds. It’s not inconceivable, but given that neither iAds nor Game Center seems to be a big money maker for the company, this seems like a rather weak argument.
Read and post comments about this article | Tweet this article
It has long been a truism among tech pundits that Apple users suffer few security attacks due to relatively low market penetration making Macs uninteresting to professional cybercriminals. That may have been true five to ten years ago, but thanks to the iPhone, iPad, and iPod touch, we can now say with assurance that obscurity is no longer Apple’s primary defense against attacks.
With over 220 million iOS devices sold, Apple dominates the tablet market and is one of the major players in the smartphone market, placing the company on the front lines of the security wars. Since the initial release of the iPhone, Apple has continually added to iOS important security defenses lacking in Mac OS X to keep up with both attacks and jailbreaks. (Every jailbreak is technically a security attack used to circumvent Apple’s iOS restrictions.)
How does this relate to Lion? Before Apple formalized the name as “iPhone OS” and then “iOS,” the operating system on Apple’s handheld devices was simply “OS X” or sometimes “OS X for iPhone.” Apple representatives made the distinct point that it was merely a variant of Mac OS X, and this was reinforced once people started jailbreaking (and later developing for) the platform. While not identical, iOS and Mac OS X are more alike than different.
Apple has been extremely clear that a key goal in Mac OS X 10.7 Lion was to incorporate lessons learned on iOS back into Mac OS X. While many of these changes were focused on the user experience — gestures, Launchpad, and so on — Apple also migrated significant under-the-hood security improvements from iOS into Lion.
With Lion, Apple has focused on three significant security improvements that have been put to the test in iOS and closed one longstanding gap in how memory is protected, along with some smaller changes.
To be clear, all of these features existed in Mac OS X before Lion in one form or another; the way Apple has combined and enhanced them to change the entire Mac application and OS ecosystem clearly shows the influence of iOS.
Hardened Memory -- As I discussed in my review of the security aspects of 10.6 Snow Leopard (“Peering Inside Snow Leopard Security,” 27 August 2009), Apple failed to implement ASLR completely. ASLR, which stands for Address Space Layout Randomization and is called Library Randomization by Apple, is a powerful security control that, when used in concert with other memory protection technologies like Data Execution Protection, makes it much harder for an attacker to compromise the operating system.
To review quickly, ASLR randomizes the memory locations of operating system and application components. This slows or stops attackers because even if they use a buffer overflow (or other memory corruption vulnerability) there are no known locations to hook into and exploit. It’s kind of like a burglar crawling through an open window without knowing whether it opens into a bedroom or a sewage tunnel.
In Snow Leopard, Apple’s ASLR implementation failed to randomize all operating system pieces, especially the important dynamic loader process, giving attackers a solid location from which to launch exploits. Lion addresses this failing, and adds other memory protections to make exploitation quite a bit harder. (This is the one area where Lion is ahead of iOS, which is still improving its ASLR).
ASLR isn’t perfect, though. Many applications still use static memory locations, and if an application isn’t compiled as a “position independent executable” (PIE), it, as opposed to the operating system, can be the target of the exploitation. Attacking non-ASLR applications on an ASLR-enabled operating system is a serious source of exploits on operating systems like Windows 7 that have used full ASLR for years. On the upside, compiling an application as a PIE is the default in Apple’s Xcode development environment for 64-bit executables targeted to Lion. Since Lion is available only for 64-bit hardware (which includes additional security protections that are supported by Lion too), it’s now much harder to exploit Macs via memory corruption attacks.
Sandboxing and Privilege Separation -- Mac OS X has long supported sandboxing — optional mechanisms in the operating system that restrict what an application can do on your system. In recent years, Apple even used sandboxing to better protect some of their more vulnerable applications, like QuickTime. (Video players are notoriously difficult to secure due to all the different encoding methods they need to support and their high performance requirements.) Sandboxing in Lion is improved in two major ways, both of which we first saw in iOS.
First are many under-the-hood improvements in sandboxing and much more robust support for applications. Lion supports over two dozen “entitlements,” which are the things an application is allowed to do. Entitlements include functions like writing to the file system (including different entitlements for temporary files), accessing the network, and interacting with hardware like the camera and USB connections. To make this work, developers design and compile their applications for sandboxing and give either an entire application, or different subprocesses, only the minimally required entitlements to work. Should an attacker exploit an application, they are thus restricted to the entitlements that application has, unless they can in some way break out of the sandbox.
Ideally, developers break their applications into separate processes, with major components sandboxed to use only minimal entitlements. Called “privilege separation,” this approach provides security controls inside an application. For example, reading PDF files, rendering Web pages, viewing videos, and using browser plug-ins like Flash are all notorious sources of bugs and vulnerabilities. Apple has separated and sandboxed the rendering processes from the core applications for Safari, QuickTime, Preview, and all Safari plug-ins (back with Snow Leopard). Adobe has already sandboxed the Acrobat and Reader applications on Windows, although they haven’t announced plans to do the same for the Mac OS X versions.
In QuickTime, when viewing a video file, the rendering engine is sandboxed and restricted from writing files. So an attacker who exploits QuickTime would also need to find a way to break out of the sandbox before they could, for example, install malware on your hard disk.
Applications on iOS are heavily sandboxed, but a quick check on my Lion system shows that not a single application I’m running, other than those provided by Apple, uses sandboxing. Even Apple’s own Aperture isn’t sandboxed.
This will all change in November 2011 when Apple implements the second major change to sandboxing and requires it for all Mac App Store apps. We don’t know how carefully Apple will review individual sandboxing implementations, but at a minimum all apps submitted to the Mac App Store starting in November will have to enable sandboxing and will be less useful as a launch point for attacks. These sandboxed applications will be able to interact with your Mac only through entitlements.
Developers aren’t universally thrilled with this change. Sandboxing is intrusive, and can be difficult to implement on existing code. It will even be impossible to sandbox certain applications that require features for which Apple has not yet designed entitlements. Those applications will still run on Lion, but Apple won’t allow them to be distributed through the Mac App Store, and that in turn may negatively affect sales, given the Mac App Store’s rapidly growing popularity as the source for Mac software.
Code (Application) Signing -- A software publisher can digitally sign an application using cryptography to assure the operating system that the application hasn’t been changed, and that it comes from a “trusted” source. A digital signature isn’t merely a few bits added to the end of an application saying “I made this”; it creates a secure cryptographic hash of the entire application binary that the operating system can use to detect tampering.
Thus an attacker can’t modify a signed application without breaking the chain of trust for its digital certificates — which means Mac OS X would refuse to launch the tampered application. To upload a compromised application to the Mac App Store, an attacker would need to sign their compromised version with the publisher’s private key and resubmit the “update” to Apple for approval (which would of course be withheld).
Application signing has been used since 10.5 Leopard, on an optional basis, for a mix of security and usability functions. For example, certain permissions (like accessing the keychain) are managed on a per-application level. Once an application is granted access to a keychain item, Mac OS X records its signature for future access to that same item. If the application is upgraded but signed with the same signature, the keychain does not need to prompt again to allow access from the new version. In Leopard, application signing played a similar role in managing per-application firewall privileges.
Code signing is mandatory for all Mac App Store apps, just as it is for all iOS apps. However, unlike iOS, there is no system-wide requirement for code signing. But code signing does assure users that apps from the Mac App Store haven’t been tampered with. The key here is not that code signing is new, but that, thanks to the Mac App Store, developers have significant incentive to implement it, and the more apps that do, the fewer can be exploited through modification.
Apple is also now using code signing more extensively for its own applications and operating system components, and it has enhanced code signing in Lion to tie it more tightly to sandboxing. Developers now have more flexibility in how they sign their code and different code components, and how those tie into sandboxing.
FileVault 2 -- FileVault is another longstanding feature of Mac OS X, but probably the one where we see the most dramatic changes with Lion. Previously FileVault would encrypt your home directory, thus protecting any sensitive files and other personal information. Combined with another feature that also encrypted virtual memory, FileVault offered reasonable protection.
But that protection came at a cost. FileVault encrypted home directories by converting them to encrypted sparse image (and later, sparse bundle) files. Each encrypted home directory was thus stored on disk as a single large encrypted file, and was highly prone to corruption. This approach also broke many backup applications, or forced them to use ugly workarounds. For example, Time Machine could back up encrypted home directories only when the owner was logged out.
Many users turned to third-party products to close this gap, but there weren’t many on the market, and some (especially PGP; see “PGP Whole Disk Encryption and PGP Desktop Professional 10.0,” 14 May 2010) had a habit of breaking with even incremental operating system updates. Contrast this to iOS, where full-device encryption has been standard since the iPhone 3GS, albeit with a few implementation flaws.
Whole-drive encryption won’t stop a network attacker, but it protects your data in case of physical loss of your drive. I recommend full device encryption for anything mobile to all my enterprise clients, but options for consumers on Macs have been pretty limited.
This situation changes completely with FileVault 2. The only thing FileVault 2 seems to share with its predecessor is a name, and use of the word “encryption.”
FileVault 2 now encrypts your entire boot disk completely transparently. You choose which users are allowed to unlock it, and only those users can boot the computer. It’s fast (unnoticeable to me), works in the background (even the initial encryption, unlike the original FileVault, which would lock your system for hours if you had a lot of files in your home directory), and works well with all backup tools.
Aside from your boot drive, you can now partition and encrypt new drives with Disk Utility. And, best of all, Time Machine even includes a checkbox to encrypt your backups.
You still need to be extremely careful with FileVault 2; if you forget your password, you are locked out of your drive forever. When you initially encrypt your system, Apple gives you two recovery options based on a 24-character code. You can write it down and use it as a recovery password, and you can store it with Apple and recover it via AppleCare after answering three user-defined security questions.
Encryption is also important for remote system wiping, one of the key security features of iOS accessed via Find My iPhone. Instead of having to format the entire drive, you just have to delete the encryption key. According to leaked information, a Find My Mac service is in developer beta and includes a remote wipe option.
Improving the Ecosystem, Not Just the System -- As I mentioned earlier, none of these changes is necessarily new to Mac OS X, and some predate iOS. Developers have long been able to sandbox and code sign their applications independently, ASLR is stronger in Lion than the current version of iOS, and FileVault 2 is a major change from FileVault, but, again, stronger than its iOS sibling.
I’ve also glossed over a number of other changes, including the XProtect anti-malware checks recently added to Snow Leopard (“Apple Responds to Increasingly Serious MacDefender Situation,” 25 May 2011), which appear unchanged in Lion, and an additional Privacy screen in the Security & Privacy preference pane that lets you control what information your Mac sends to Apple and your location services preferences.
But it’s when we take a step back that the pieces fall together and show how Apple is building security into the entire ecosystem, much as it did in iOS.
The most profound change is the combination of memory protection, sandboxing, and code signing updates with the Mac App Store. While users can still install whatever they want on their Macs, those who choose software from the Mac App Store will know (or at least benefit from the fact) that their applications enforce a security baseline that’s currently rare in even major packaged applications. Compromising applications is a major vector of attack. Almost all of the recent major attacks against users (as opposed to business applications) I’m aware of rely on flaws in applications like Safari, Microsoft Excel, QuickTime, and Adobe Reader.
While I don’t see Apple forcing all Mac users to use only the Mac App Store, I could see a future — either a system preference or even a special Mac — where some users are restricted in this fashion. Those users would be protected from malicious downloads and other tricks used to install malware. It wouldn’t work for everyone (me, for example, or any developer), but the popularity of iOS devices and the iOS App Store proves there is a very large user base that can be more than satisfied choosing applications from a walled garden.
Remember the recent MacDefender attack, which tricked users into installing a malicious application? Imagine if instead of just asking for an administrator password, a dialog informed the user that a new application was not approved by the Mac App Store, and directed them to System Preferences to override the block. Some people would still fall for it, but over time, as users are trained to focus on the Mac App Store for trusted applications, I bet the numbers would be far lower.
Some enterprises already do something similar with special “whitelisting” tools to restrict what employees can install, thus preventing malware. This strategy can be highly effective, albeit often hard to manage, depending on the habits of those employees and how strictly the rules are enforced.
Let’s be clear about Apple’s motivations here. This is clearly a case where Apple will profit from security since they get a share of every application sold in the Mac App Store. But, as someone who had to spend part of a recent weekend cleaning a relative’s Windows-based PC of malware, I don’t care that much as long as it works for users who are otherwise at risk.
The changes in FileVault 2, and the impending Find My Mac, show that Apple also recognizes the demand for better security on mobile computers. Apple has sold many more laptops than desktops in recent years, and this trend has continued even after the release of the wildly popular iPad. Although the combination of encryption and remote wiping has long been an option for enterprise users, Lion is the first time we’ve ever seen it built into a consumer operating system (even Microsoft’s BitLocker full-drive encryption is an option only in its Ultimate and Enterprise versions).
In the end, Lion is significantly more secure than Snow Leopard even without the Mac App Store ecosystem. Combine the two, and we can see a future where we have security options never before available to consumers, and, more important, where security is an integral part of the overall ecosystem such that even those who know nothing about security are well protected.
Although you must take many factors into account when deciding when to upgrade to a new version of Mac OS X, from a security standpoint, the sooner you upgrade to Lion, the sooner you can benefit from Apple’s security improvements.
Read and post comments about this article | Tweet this article
Mac OS X 10.7 Lion, has been, by all accounts, a sales success, with over one million copies downloaded on its first day of release and undoubtedly millions more since. These stellar sales results do not necessarily reflect a perfect product, but merely one that has been much discussed and long anticipated. Just as with the initial releases of 10.6 Snow Leopard, 10.5 Leopard, 10.4 Tiger, and all the other big cat releases, this one has its share of minor changes from previous versions that irritate and baffle, plus new bugs that confound and confuse.
Don’t misunderstand the point of this article. Our goal is to call out subtle aspects of Lion that feel as though they’re making us — and many other long-time Mac users — less productive on our Macs. Our hope is that Apple will revisit the discussions that resulted in these changes to Lion and reevaluate how they affect not just usability for new customers, but productivity for loyal Mac users who live and die by their Macs. And, for those who might have felt that using Lion seemed awkward but couldn’t quite identify the issues, perhaps our descriptions will let you figure out how to adjust your workflow to compensate.
Here are some of the minor cosmetic and operational changes that have irked us.
Hidden Scrollbars -- The utility of being able to tell at a glance how long a page is and roughly where you are in it is key for some of the things we do (editing in a very long document, for instance). Luckily, you can set scrollbars to appear at all times — not just when you’re scrolling — in the General preference pane.
Also, even when they are showing, Lion’s scrollbars present a smaller, harder-to-hit target for a pointing device than scrollbars in previous versions. We don’t expect Apple to change anything here; their goal would seem to be to encourage everyone to scroll via a trackpad or Magic Mouse rather than by clicking the scrollbars.
Finder Sidebar Icons -- The monochrome-only icons in the sidebar of Finder windows — even for custom folders — makes it significantly harder to pick out particular items in the sidebar list. What’s more, custom icons for folders do not appear in the sidebar, showing every non-Apple folder as a generic folder icon rather than using the icon that the user has supplied.
Again, we don’t expect this to change any time soon; Apple is in a monochromatic design phase right now (witness the recent updates to iTunes). It is unfortunate that Apple’s design imperatives are overriding what is largely a functional feature — color and custom icons are significant visual cues in interface navigation.
Mission Control’s Spatial Unpredictability -- In Spaces in Snow Leopard, now subsumed into Mission Control, you could set up two or more desktops in a two-dimensional grid, and switching between them with Control-left-arrow or Control-right-arrow key presses always revealed individual desktops in a predictable sequence. Now, in Mission Control, the desktops are arranged linearly, and, by default, those desktops are ordered depending on which one was most recently used: the desktop that appears to the right or left of the current desktop may not be the same one that was there a few minutes earlier. Fortunately, this default behavior can be changed in the Mission Control preference pane.
What’s more, the desktops in Spaces wrapped around the grid: once you were viewing the “last” desktop in the grid, the next Control-right-arrow would take you back to the “first” desktop. In Mission Control, the line of desktops doesn’t wrap around: when the user is viewing the final desktop in the line of desktops, the next Control-right-arrow does nothing, except to make the currently displayed desktop jiggle for a moment. To get from the rightmost to the leftmost desktop can require quite a few key presses. And there’s no System Preference setting that can alter that behavior.
It’s good that you can make desktop position in Mission Control predictable if you wish; it would be nice if Apple would enable wrap-around access to desktops as well. It’s possible Apple removed this capability to make switching between desktops more like switching between Launchpad pages, which also don’t wrap around, much as Home screen pages don’t wrap on iOS. On the other hand, the bookshelves in the iBooks app on iOS do wrap around, so it’s not like Apple is completely opposed to wrap-around navigation.
Apple Mail’s Reply within Conversations -- In Apple Mail, when viewing a conversation, you often want to respond to a message that has just arrived as a response to a previous email that you sent. When Mail’s conversation feature is active, those responses can be visible and completely readable in Mail’s browser window even if they haven’t technically been “read” yet; instead, the selected message in Mail is still the last message you clicked, which is often a message that you sent.
So, if you click the Reply button in the toolbar or use the keyboard shortcut, you create a reply to the currently selected message in the conversation, which is not the just-received response, but the message you sent that elicited the response. As a result, your “reply” is really a reply to your message, not a reply to the most recent message that just arrived in the conversation. You have to remember to click within that response to reply to it. Otherwise, you end up sending your reply to yourself — great if you’re feeling lonely; not so great if you want to keep the conversation going.
(As an aside, you can choose in Mail’s Viewing preference pane whether the most recent message in a conversation appears at the top or the bottom of the conversation. Most recent at top is like Twitter, whereas most recent at bottom is like most discussion forums. We generally recommend most recent at bottom, since otherwise you have to read threads that are new to you from the bottom up, which is awkward.)
This sort of user experience tuning often takes place in subsequent releases, since it’s hard to know what most users want to do before many people have seen the feature. For what it’s worth, Gmail, which pioneered the concept of conversations, is quite good about this. Every individual message in a conversation has its own Reply and Forward links (to be fair, Apple Mail has them, too, but in Apple’s war on user interface discoverability, they don’t appear unless you hover over the message header); if you click in a message and then use a keyboard shortcut, Gmail replies to the message that was selected; and if all else fails, Gmail replies to the last message in the thread. Hopefully Apple Mail can learn from Gmail’s example.
Three-finger Salute -- Swiping three fingers up or down in Snow Leopard moved you (in some programs) to the top or bottom of a document or page, the equivalent of pressing the Home or End key. In Lion, that helpful gesture is gone, replaced with a system-wide setting: the three-finger swipe up is either select-and-drag or reveals Mission Control, and the three-finger swipe down is either select-and-drag or App Exposé. You can reassign Mission Control and App Exposé to four-finger swipes, but if you want the three-finger swipe for Home and End back, you’ll want to install one of these utilities (in order of their success of providing that particular feature): jitouch, MagicPrefs, or BetterTouchTool.
Auto Save -- Lion allows applications that support Auto Save to save data automatically without user intervention. Working hand-in-glove with Versions, Auto Save not only prevents users from worrying about losing data by forgetting to save, but also gives them a way to go back in time to earlier versions of a document and revert some or all of the most recently autosaved changes. That is spiffy, but Auto Save can’t be turned off in applications that support it, and its mere presence eliminates a common File menu option: Save As.
In pre-Auto Save versions of Mac OS X, you could open a document, immediately choose File > Save As, name the copy, and begin working, leaving the original intact. Now you must open a document, choose File > Duplicate, rename the duplicate, and (optionally) manually close the original in order to work on a copy without affecting the original. Should you forget to duplicate the document immediately, any changes end up automatically saved in the original document; in the old model, no changes are saved until a manual Save or Save As command is issued.
Speaking of Auto Save, we’re not fond of the hidden menu you use to access versions — hover your cursor over the name of the document in the title bar, and you’ll see a tiny downward-pointing triangle to indicate the menu’s presence. Click it to access commands for duplicating, locking, and browsing versions of the document. This is yet another example of Apple’s newfound penchant for hiding essential user interface elements. For something as necessary as accessing a previous version of a document, it’s way too hard to find these controls.
We don’t see Apple changing anything here; we include this item more to alert those upgrading to Lion to how you’ll do the equivalent of a Save As in Auto Save-savvy apps and how you access older versions of your auto-saved documents.
Auto Termination -- There isn’t much to say here that Matt Neuburg has not already said in “Lion Is a Quitter” (5 August 2011). Apple could largely resolve Matt’s complaints by making the Dock and Command-Tab app switcher continue to show icons for apps that have been terminated by the system, much as the iOS Fast App Switcher shows all recent apps so the user doesn’t know or care if they’re running.
Resume on Restart/Reopen -- Whenever you quit an application in Lion, the next time you launch that application, it opens with the same windows showing as were present when you previously quit it. That may generally be desirable, but it isn’t always. The built-in solution is to press Command-Option-Q to quit and discard open windows, or hold down Shift when you launch an application to have it not open previously opened windows. And you can deselect the “Restore windows when quitting and re-opening apps” checkbox in the General preference pane to disable the feature globally.
But you can’t disable the feature on a per-application basis: it’s all or nothing. When it comes to restarting a Mac, the situation is even less configurable: you can deselect the “Reopen windows when logging back in” checkbox when you shut down, log out, or restart, but you have to do it each and every time — there’s no way to disable that feature permanently.
Even though power users may want application-level control over Resume, it’s hard to see Apple providing it, since it would add a significant amount of user interface overhead, either somewhere in System Preferences, or in every individual application that supports Resume. It would be nice to be able to toggle the default restart behavior so the “Reopen windows when logging back in” checkbox would be deselected by default; this is the sort of thing that’s often handled by a hidden
defaults write command.
The Unbearable Slowness of Help -- This problem is not new in Lion; Help has been unacceptably slow for quite a while. That it’s still a problem in Lion is disappointing. An application’s Help menu should be the first place a user goes when trying to solve a problem or figure out how to use a feature, but the Help window takes several seconds before any useful information appears in it, and the Search field in the Help window often takes several more seconds before whatever the user has typed even appears. As a result, users may assume that Help is broken, and never again try to use it. Come on, Apple, it’s always annoying when you have to wait to get help on the phone or in a store, and it’s no different on the Mac.
iChat Stuttering on Yahoo -- iChat in Lion now supports Yahoo IM accounts. But the feature seems to have an interesting bug for some users: whenever they begin to type a message in iChat to a Yahoo contact, iChat immediately begins to send what they are typing before they hit Return. And as they keep typing, iChat continues to send everything they have typed up to that moment as individual messages. For example, suppose one types, “Hi. Lovely day here in the wonderful land of Oz.” iChat sends multiple messages in a sequence that looks something like this:
Hi. Lovely d
Hi. Lovely day her
Hi. Lovely day here in the won
Hi. Lovely day here in the wonderful land of Oz.
Hopefully this bug will simply disappear with iChat’s next update.
Smart Folders Are Broken -- Not completely, of course, but the problem appears when you save a Finder search as a Smart Folder and later attempt to modify the search. If you choose to view a Smart Folder’s search criteria in the Finder, two things happen:
The criteria shown are the defaults (no search string is present, and there is only one criteria bar shown, with Kind set to Any) instead of the terms and criteria you had entered.
The previous search criteria are not just not visible, but deleted, rendering that Smart Folder useless.
This is clearly a bug, and it was a little surprising that Apple didn’t fix it in 10.7.1.
Screen Wakes Require Keyboard Access -- This is truly minor, but it threw us and several colleagues briefly. Before Lion, if your Mac’s screen had gone to sleep, you could bring it back to life by moving the mouse or touching the trackpad, as well as by pressing a key on the keyboard or clicking the mouse button. Since there was always a worry that a subsequent key press might insert a character in an unwanted location (we writers hate that), we generally opted for the mouse or trackpad. But Lion now ignores mouse or trackpad motion for waking the screen, forcing us to click the pointing device button or tap a key on the keyboard. It’s not a big deal, but we can’t imagine why Apple would have made the change. Perhaps it’s just an oversight and it will return in a future update.
Looking Forward to 10.7.2 -- All of this is not to suggest, of course, that Lion is a disaster. Far from it. Much about Apple’s latest version of Mac OS X is exciting, some of its new capabilities are inspired, and most of it works well. However, as with many 10.x.0 releases, this big cat could benefit from a flea-bath and some mane-trimming in a future update. 10.7.1 has just appeared, and it doesn’t address any of the issues we raise here, so now we’re looking forward to 10.7.2.
Read and post comments about this article | Tweet this article
Read/post comments about Firefox 6.0.
Dropbox 1.1.40 -- Online storage service Dropbox has updated its eponymous client software to Dropbox 1.1.40, bringing back to Mac OS X 10.7 Lion status badges on Dropbox-managed files and folders so you can tell whether or not they’re updated. It also fixes a rare problem where certain Mac OS X machines wouldn’t upload files automatically. In theory, Dropbox is supposed to update itself, but it often doesn’t, in our experience, so it’s worth getting this update manually if you’re using Lion. (Free, 17.6 MB)
Read/post comments about Dropbox 1.1.40.
GraphicConverter X 7.3.1 -- Although Lemkesoft’s GraphicConverter X 7.3.1 received a only minor version bump, the update comes with a large number of enhancements, including new options for manipulating images and previews, improved drawing functions, and the capability to display GPS location data embedded in image files. Support for Mac OS X 10.7 Lion has also been improved with the reintroduction of support for the operating system’s full-screen mode. Several smaller bug fixes and feature tweaks round out the update. ($39.95 new from Lemkesoft or from the Mac App Store, free update, 100 MB, release notes)
Read/post comments about GraphicConverter X 7.3.1.
Carbon Copy Cloner 3.4.2 -- Bombich Software has released Carbon Copy Cloner 3.4.2; despite the minor version hop, this release includes dozens of bug fixes that affect several areas of the backup utility’s functionality, including scheduling, the handling of network filesystems, access permission management, and so on. In at least one case, the fixes address issues that could cause a restored volume to be un-bootable under some circumstances. A number of minor feature tweaks round out the update. (Free update, 5.2 MB, release notes)
Read/post comments about Carbon Copy Cloner 3.4.2.
ScreenFlow 3.0 -- New from Telestream is ScreenFlow 3.0, a major upgrade to the company’s screencast recording app. The new release brings a number of new features, including compatibility with Mac OS X 10.7 Lion. ScreenFlow now allows users to create freehand callouts and annotations anywhere on a video using a brush or rectangle tool. The app’s timeline has received a facelift that provides additional flexibility in editing operations and is complemented by new audio quality controls and filters. Rounding out the update are new export settings, which now include an iPad preset and an option to publish to Vimeo. ($99 new, $29 upgrade, 14.5 MB)
Read/post comments about ScreenFlow 3.0.
Airfoil 4.5.5 -- Rogue Amoeba has released Airfoil 4.5.5, a minor update to its popular remote audio transmission app. The main focus of the new version is the correction of several issues related to Mac OS X 10.7 Lion, one of which is a severe crash. In addition, Airfoil now sports improved compatibility with Google Talk, Muse Controllers, and Radium (although the latter requires an as-yet-unreleased version of the Internet radio player app). ($25 new, free update, 11.3 MB, release notes)
Read/post comments about Airfoil 4.5.5.
We were just monkeying around last week, with Glenn Fleishman talking on NPR’s Science Friday and with an article about orangutans using iPads. Both are worth checking out.
Glenn Discusses Google Purchase of Motorola on Science Friday -- Glenn Fleishman appeared on the National Public Radio show Science Friday to talk with host Ira Flatow about the implications of Google’s acquisition of Motorola, and what that means for Apple and consumers.
Orangutans Play with iPads -- After an April Fools’ Day joke about gorillas using iPads, Scott Engel, who works with orangutans at the Milwaukee County Zoo, decided to set up an iPad enrichment program for the zoo’s orangutans. Brian Cecente of Kotaku writes about how the orangutans are getting started with the iPad, and how other zoos are considering adding iPads to their primate enrichment programs as well.