Annual OS X Release Cadence

In the late 1990s through the mid 2000s Intel found itself in a situation where it was heavily invested in a microprocessor architecture that ultimately had no future. Intel's platform strategy at the time was also guilty of making the wrong bets. Additionally the company was experimenting with broadening its focus and shifting from a microprocessor manufacturer to a silicon manufacturer. The combination of all of these factors left Intel in an extremely vulnerable state, one that its competitors were able to take advantage of.

VIA Technologies, a fairly low-cost player in the chipset business back then, was able to see real success selling chipsets to customers who were displeased with Intel's offerings. The bigger and more painful surprise was that AMD, Intel's chief competitor in the x86 CPU space, was able to gain significant marketshare for the first time in its history.

For Intel, the painful learning experience resulted in an internal mandate: no more surprises. Intel invested heavily in competitive analysis groups that would model the expected performance of the competition's roadmap and feed that data back into the development cycle for its own technologies. The other major change was a shift to a two-year architecture cadence, now known as the tick-tock model.

Significant architecture changes every two years, separated by minor updates and process node shrinks during the interim years guaranteed that Intel's product lineup would always remain fresh. The other thing tick-tock guaranteed was that Intel would only be on the hook for two years with any given architecture. Should the competitive analysis teams have missed something, a two year cadence would make any major course correction feasible before significant marketshare was lost.

While the tick-tock model was somewhat unbelievable in '05 - '06, it makes a lot of sense today after more than a couple successful iterations of it. More recently, Microsoft announced a planned shift to a 3-year OS release cadence. Just last week, Apple announced a move to annual releases of OS X. The benefits of an aggressive release schedule are clear, the question is whether or not it's a model that will work in software like it has for Intel in hardware.

Mountain Lion is supposed to be the first instance of this yearly OS X release cadence. In speaking with Apple it's clear that annual OS X releases is the goal, however we may see some fluctuation. I wouldn't be surprised if over the next few releases Apple doesn't stick to a 12-month cycle, but instead allows for some wiggle room. While Intel's tick-tock model is generally viewed as a success, historically we haven't seen a new microprocessor from Intel every 12 months on the dot. Both in the hardware and in the software space we're talking about major projects requiring, at times, hundreds of engineers. Maintaining a strict schedule is near impossible, but it's important that the goal is there.

Prior to Mountain Lion, major OS X versions were released about every two years. Panther, Tiger, Leopard, Snow Leopard and Lion were released in 2003, 2005, 2007, 2009 and 2011, respectively. Mountain Lion is scheduled for release this summer, likely around 12 - 13 months after Lion's July 2011 release.

Apple's motivations for moving to an annual release cycle for OS X are obvious. Through small but consistent evolution Apple has been able to build iOS from a platform at a feature deficit to the incumbents to an industry leader. It's not uncommon for companies to look at financially successful models internally and apply them to other business units with hopes of achieving similar results.

The Mac business unit isn't in trouble by any means, but as Microsoft becomes more aggressive in wanting to defend Windows' territory Apple is more motivated to respond in kind. Windows 8 is a highly anticipated release from Microsoft and I don't believe it's a blind coincidence that the first preview build of Mountain Lion was made available to developers thirteen days before the Community Preview release of Windows 8. As different as the typical Mac and Windows PC consumers may be, Apple and Microsoft view the audience as a whole as tasty potentials.

There are also the engineering benefits of an aggressive release schedule. We've seen the impacts of tick-tock from Intel and ATI's old philosophy of showing up to the fight. An annual release cadence, at least on the hardware side, tends to trip up the competition more and work out pretty well. Again, it remains to be seen how well this philosophy maps to major OS releases but in theory, it's good.

Finally we have the fluffier benefits. Version numbers get bigger, quicker. There are more PR opportunities and customers generally like getting new things. In the iOS world these updates come for free, so long as you aren't running unsupported hardware. Although Apple has done a good job of lowering the price of OS X over the years, it's unclear whether or not it's going to take the final step and give away the OS for free. OS X as a whole is a bigger, more complex project than iOS (part of why the annual cadence is going to be more difficult to pull off) so I can understand the justification of charging for each update. But from a general consumer perspective it remains to be seen if the expectation for free updates will become commonplace or not.

All in all, a more aggressive release schedule can be a good thing. We've seen it with individual applications (Chrome) but not as much on the OS side. There's the danger of changing too much, too quickly, but Apple has historically done a good job of staying on the right side of change when it comes to OS X. What will this do to point releases? Will we see just as many of them or fewer as a result of the shift in strategy? I suspect the latter will ring true unless Apple decides to significantly grow the OS X team. The bigger question to me is whether or not we'll see a similar move from Microsoft. Each OS X release was always punctuated with slight UI differences that made newer releases feel, well, newer. It's not about implementing dramatic shifts in the UI paradigm every year, it's about the slight changes that make something feel newer or different. It's a mid-cycle refresh in a car maker's lineup. Logically it's not enough to warrant trading your two year old car in on the updated model, but emotionally it makes us do stupid things. Years ago I remember hearing that PC manufacturers were hoping to imitate the automotive concept of buying computers by model year vs. specs. Apple got the closest out of anyone to achieving that goal and its OS X strategy is clearly designed to be in line with that.

General Impressions: The iPad-ification of the Mac

With Mountain Lion Apple officially drops the Mac prefix to the OS, it's now simply OS X 10.8. It's interesting (and perhaps deliberate?) that Apple keeps speaking of the updates in Lion/Mountain Lion as bringing iPad features to the Mac, not just iOS features. Perhaps that speaks to the nature of the convergence we'll see going forward.

There was a time in the microprocessor business where AMD and Intel felt that the ideal architecture for low power was mutually exclusive with the ideal architecture for high performance. Over time it became very evident that what makes you power efficient often gives you great performance as well. What we saw was a unification of mobile and desktop CPU architectures as a result. Although you could argue that the same sort of product bifurcation is happening now with the popularity of smartphone SoCs, I suspect we'll eventually see more convergence there in terms of features over time.

I do wonder whether we'll see a similar transformation in the OS space. Much of the discussion has been focused around bringing iOS user experience and features to OS X, however I'm more curious about whether we'll see a more fundamental merging of the two OSes over time. Today Apple has an i and an X line of operating systems, but what's to say that we won't see an eventual unification there. In many ways this would be a motivation for OS X on ARM, but it's a similar (and possibly a stronger) motivation for iOS on x86.

For this developer preview, the download and installation processes are identical to Lion - you still get the OS from the Mac App Store, it still creates a recovery partition for diagnostic and reinstallation purposes, and it still looks and acts mostly the same. If you made a USB or DVD installer for Lion from the App Store installer, that method continues to work here.

The Mountain Lion Finder, along with Lion additions like Launchpad and Mission Control, are at this point largely identical to their Lion counterparts. There are two obvious new features right now: first, Launchpad now includes a search box at the top of the window that lets you browse your installed apps. Compared to Spotlight, I find it to be of dubious usefulness, but I'm already on the record as finding the whole Launchpad concept to be of dubious usefulness - take my opinion as you will.

The other addition is also vaguely iOS-ish - you can cancel file copy operations in progress by clicking an X in the icon's upper left-hand corner (see above). Once a copy operation is complete, you delete the files by dragging them to the Trash just as before.

Safari 5.2

Safari 5.2, which is also currently available to developers as a beta for Lion, bumps the browser's WebKit version to 535.18.5, and brings with it some performance improvements and features. Features first: tabs now work as they do on the iPad, with each tab taking up an equal amount of space across the window - in Safari 5.1 and most other desktop browsers, new tabs are a fixed width (in both cases, the tabs begin to contract as you open more of them).

The address bar and search bar in the new Safari are also unified (as in Chrome and IE) - when you begin typing, the browser will search your default search engine, your bookmarks and history, and the content on the current page for matches. The Safari Reader button is now present to the right of the search/address bar at all times.

There's a new passwords manager in Safari that allows you to view and remove any stored user name/password combinations for websites you've visited. In the past this information was only accessible through the OS X Keychain but now it's available in both places.

Now, for performance - Safari 5.2 is measurably faster than Safari 5.1.3, and while it doesn't beat the latest stable versions of Firefox or Chrome in the tests below, the upgrade at least keeps Apple's default browser competitive. The problem is that this performance is a moving target - if Safari 5.2 doesn't launch before Mountain Lion's release this summer, both Mozilla and Google will have released several minor upgrades to their browsers that may help them pull even further ahead of Apple's latest. Interestingly enough the new Safari is actually faster than the latest stable build of Chrome in SunSpider but it loses everywhere else. Subjectively Safari feels fast but still not quite as fast as Chrome, although the two are much closer now.

These tests were run on a late 2010 MacBook Air, which runs a 1.6 GHz Core 2 Duo - please try to remember that before you laugh at any of these scores.

Apple Remote Desktop and Screen Sharing

The Apple Remote Desktop client in Mountain Lion has been updated to 3.6, which continues the years-long tradition of bumping the ARD version to support a new OS X release without adding enough fuctionality to justify a major version change. ARD gains IPv6 support and can now report information about batteries, trackpads, and Thunderbolt peripherals, but none of this fundamentally changes how the software works.

On a related note, Screen Sharing is made marginally more functional by the addition of controls at the top of the window - they don't really add anything that wasn't there, but they pull functionality that was previously hidden in menus and expose it to the user. Screen Sharing also supports drag-and-drop file sharing between connected computers, something previously limited to the full Apple Remote Desktop package.

Gatekeeper

Of the Mountain Lion announcements, Gatekeeper has been one of the most discussed. Apple has touted OS X as being a safer, more secure environment than Windows, offering its customers a relatively malware-free experience. In the early days this was often discounted by saying that OS X wasn't a likely target for malware simply because no one used it. Today Apple claims to have a Mac installed base of 63 million users. While there are far more Windows users, that's not an insignificant number. And it's growing.

As the likelihood for significant malware targeting OS X increases, Apple must do whatever it can to maintain its pristine image. In a sense, Apple made its bed by promising a more secure, virus/malware-free experience, and now it has to sleep in it. It's not a bad thing, but it's something that is going to require a lot of work.

The easiest and most obvious solution to the problem is the Mac App Store. Every app distributed through the Mac App Store is certified by Apple and thus no malware/viruses should ever make their way to a customer's Mac if they only run apps from the Store. That's a step in the wrong direction unfortunately. Companies like Adobe and Microsoft don't make their applications available in the Mac App Store (paying Apple 30% for every copy of Photoshop sold seems unlikely to happen), not to mention the tons of useful open source or other programs that aren't distributed through the MAS. While the iPhone can sell just fine as a platform that's more of an appliance, Macs (at least today) cannot.

The alternative is to heavily warn users that what they're running isn't exactly safe but allow applications, regardless of origin, to be run. This is what's done today in Lion. The first time you run an application that you downloaded you'll get a message that looks like this:

It's the everlasting debate between freedom and security. Give up one to get the other, but what's the right balance?

The compromise in Mountain Lion comes in the form of a tool called Gatekeeper. An innocuous little radio selection in the Security preference pane, Gatekeeper lets you choose what applications can be run on your Mac.

You can choose to only allow applications from the Mac App Store, allow all (the two extremes we discussed above) or pick an in-between option: allow anything downloaded from the MAS or anything by an identified developer.

This in-between setting is the compromise.

If a developer joins the Mac developer program ($99/year) it can become an officially identified developer with Apple. The developer can then sign its applications with a unique cryptographic key that Apple recognizes, without requiring that the apps be distributed through the Mac App Store. Unlike the Mac App Store, there's no approval process that the developer's signed apps need to go through. There's only one stipulation that goes along with the identified developer label: the apps distributed with that key cannot be malware.

Apps from identified developers will communicate with Apple's servers to verify the digital signature is intact and correct only upon install or the first run of the application. Subsequent runs do not phone home and there's no remote kill switch for these applications. Should Apple find out that a developer has been distributing malware Apple can revoke the developer's key, but that would only render those apps that have yet to be installed/run from working. Without a certification process for non-MAS apps there's still a degree of risk associated with this compromise. I don't believe the ideal solution is to force everyone to buy through the MAS, but Gatekeeper's compromise isn't an impervious solution.

Apple tells us the default Gatekeeper setting in Mountain Lion will be to allow apps from the Mac App Store or from identified developers to run. Hopefully by the time Mountain Lion ships many third party developers will be on-board and identified making the transition mostly seamless. If you don't change the default Gatekeeper setting there's another way around the protection: simply control-click (or right click) on the app you're trying to run and select open. Doing so will override the Gatekeeper setting and let you run an unsigned app.

Software Updates & Moving Toward the Mac App Store

To be honest, I rarely use the Mac App Store. I appreciate it because it does let me quickly get Apple applications without fumbling for a restore DVD somewhere, but otherwise I get all of my non-Apple apps directly from the source. The app store makes sense to me on iOS because that's the only option we were presented with from the start, but even there I would appreciate the flexibility of installing apps from any source. On a Mac the opposite is true. Just as was the case on PCs, I've always grabbed and installed software on my Macs from a multitude of sources and I've never really wished there was a centralized, policed repository of Mac applications. That being said, I do understand and accept that I may be a part of a shrinking minority. Apple's most successful products have been those sold effectively as appliances. The MacBook Air took many steps in the same direction by offering no end user upgradeable CPU, memory, storage or battery options. With the MBA you're buying some sort of a Mac appliance hybrid. It's a good device (I'm typing this article on an MBA now), but in many ways it's an inflexible one.

My fear is that as Apple straddles this line between the old and the new, that it will step over too far into the walled garden/appliance territory. That OS X, just like iOS, will become a platform powered only by the app store. That isn't the reality today and I hope that it never will be, but the temptation is surely there. Apple gets a cut of all software sales through the Mac app store, it doesn't elsewhere. App stores are a way of continuing to profit off of a platform after you've sold the initial hardware and operating system. From a customer experience standpoint there's also significant motivation behind supporting only a centralized app store. With complete control of what can run on the platform, Apple could guarantee and maintain the level of experience that it's always been in pursuit of.

Again, today, this isn't a problem but there's definitely movement in that direction. Mountain Lion does away with Lion's Software Update mechanism and instead integrates that into the Mac App Store directly.

There's no change in functionality, just a change in physical location. I will admit that the software update tool always felt like it needed...updating, but I don't know that I would've put it in the MAS application.

Remember all of the new APIs that developers now have access to? A couple of them are only available to applications distributed via the Mac App Store. The big one is iCloud. Any application that interfaces with or uses iCloud is required to be in the MAS. It's the tradeoff you make when you start using Apple's cloud storage as a selling feature of your application. There are ways around this requirement (you could decouple any cloud storage features from your main application and simply offer the former through the app store) but it's a bifurcation of the Mac software feature set for the most part.

The notification story is a little different.

New Notifications API & Interface

Revamping notifications was a major part of the iOS 5 update last year and Apple decided to bring some of that to OS X. Mountain Lion sports a new iPad-like notification center that's accessible by performing a right to left, two finger swipe on a multitouch trackpad. The gesture is unique in that it's the first gesture that must be started at the very edge of the trackpad. A two finger right-left swipe starting in the middle or even an inch from the border of the trackpad is different entirely. To bring up the notifications menu you have to start the gesture at the very edge of the trackpad. It's easier to just start swiping off of the trackpad first, allowing the gesture to then continue onto the trackpad surface. The notification center gesture is very reminiscent of the PlayBook/webOS bezel gestures that have similar requirements for starting outside or at the beginning of the touch area.

Notifications are summarized in the notification center but as they happen they appear in a little box in the upper right of your screen. You can configure notifications to accumulate or automatically disappear after a short period of time. Growl users have had something similar for a while now, but Apple is now officially offering a native notification service to all developers.

There's been a bit of confusion about the new notifications API (NSUserNotification) and whether or not it's available to applications not in the Mac App Store. Local notifications using the new API are available to third party apps regardless of their distribution model (they don't need to be in the Mac App Store). Push notifications on the other hand currently require that the application is distributed only through the Mac App Store. The key word is currently because a lot of Mountain Lion decisions have yet to be finalized. I wouldn't be too surprised if Apple decides to open up push notifications, in some form, to third party applications not distributed through the app store.

This is another example where Apple has to carefully straddle the line between pushing everyone to the Mac App Store and not abandoning the rest of the Mac software ecosystem. I would like to see feature parity regardless of distribution model (perhaps with some restrictions) on OS X going forward, but I'm not sure that will happen.

Messages

One of the more tangible features of Mountain Lion is Messages, the iChat replacement that's long overdue. The main attraction is the ability to send messages to iMessage users from your Mac. The feature works and is available to Lion users as well through a beta, however the final version will be a Mountain Lion exclusive.

AirPlay Mirroring & QuickSync

Since Arrandale Intel has been offering its own flavor of wireless display technology called Intel WiDi. The premise is simple - take the display buffer, encode it in real time as a video (originally MPEG-2, later H.264), send it over WiFi to a box that can decode the video stream and display it over HDMI to an attached display (e.g. a HDTV). Apple enabled something similar on its iDevice platforms called AirPlay Mirroring. Deploying AirPlay Mirroring on iDevices made sense since all of those platforms ship with hardware encoders on their SoC. With Mountain Lion Apple is bringing the same functionality to Macs. The only requirements are that you have a second generation Apple TV and that it's on the same network as your Mountain Lion Mac.

AirPlay Mirroring isn't functional currently but by the time ML ships it should be. The usage models are plentiful (presentations, quickly tossing videos on the big screen for many users to watch, etc...) and the feature should do a good job of selling Apple TVs to Mac users.

Apple isn't being very specific on what hardware platforms will support AirPlay Mirroring. Sandy Bridge and later Macs shouldn't have a problem and I hope that Apple will leverage Intel's QuickSync technology to keep CPU utilization low. It's possible for earlier Macs to handle the encode workload but there's obviously a performance tradeoff. Apple is usually very sensitive to maintaining user experience over guaranteeing functionality so it'll be interesting to see where it draws the line for AirPlay Mirroring compatibility.

Unfortunately there's no update on QuickSync support elsewhere in Mountain Lion. Thus far all Finder and Quicktime initiated video transcoding is done in software on the x86 cores and doesn't appear to leverage QuickSync at all. Why Apple generally refuses to use one of Sandy Bridge's most valuable features for consumers remains a mystery to me.

Server

I won't dive too far into Mountain Lion Server, since this is just supposed to be a quick first look at a very early version of the product. However, for users of the product (and/or readers of our huge Lion Server review) there's one important change that comes in with 10.8 - Lion introduced a new program, Server.app, which took over some (but not all) of the functionality provided by the legacy Server Admin Tools. The tools are still provided as a separate download to close the functionality gap left by Server.app.

In Mountain Lion Server, more functionality of the Server Admin Tools appears to have been integrated into Server.app - NetBoot, the System Image Utility, DNS, and a few other services can now be managed in Server.app. There are still a few services that appear to be missing (DHCP, NAT, and a few others appear to be absent) - it's too early to say whether these services will be included in Server.app when Mountain Lion is launched, whether the company will offer a new version of the Server Admin Tools, or whether those services will be removed from OS X Server altogether.

Supported Macs

The last thing I wanted to talk about is something we've already touched on, but it bears repeating - Mountain Lion is dropping support for any Mac that is not capable of booting OS X's 64-bit kernel. Lion requires a 64-bit capable Core 2 Duo processor or better, but included the legacy 32-bit kernel to enable support for computers missing one of the other two components required for a 64-bit boot: a 64-bit EFI, and 64-bit graphics drivers. The complete list of supported Macs is below:

• iMac (mid 2007 or later)
• MacBook (13-inch Aluminum,  2008), (13-inch, Early 2009 or later)
• MacBook Pro (13-inch, Mid-2009 or later), (15-inch, 2.4/2.2 GHz), (17-inch, Late 2007 or later)
• MacBook Air (Late 2008 or later)
• Mac Mini (Early 2009 or later)
• Mac Pro (Early 2008 or later)
• Xserve (Early 2009)

Generally speaking, if you don't want to use this Apple Support document to see whether your Mac supports the 64-bit kernel, there are a few rules of thumb you can use: if your Mac uses either the ATI Radeon X1600, Intel's GMA 950 or X3100, and any NVIDIA GeForce card older than the 8000-series, your Mac is likely disqualified from running Mountain Lion. This list includes computers (like the pre-unibody white MacBooks) sold just a little under four years ago, which is no doubt unwelcome news to users of those systems - unfortunately, you'll either have to upgrade your system or stick with Lion if you've got one of the unsupported Macs.

Some have reported that the Mountain Lion Developer Preview will install and run on some of these unsupported Macs without issues, but if you'll recall, early Lion previews could also be made to run on 32-bit Core Duo and Core Solo processors that were dropped from the support list. If the system requirements for the preview are in fact representative of the requirements for the shipping version of Mountain Lion, expect booting on those older machines to be blocked at some point in future previews.

Is it Safe to Use & The Future

Mountain Lion does still have some rough edges and there's an extensive list of known bugs. The OS is usable if you're wondering whether or not you can install it on a secondary machine and live with it. I would caution anyone against migrating their primary system to it unless they're ok with dealing with some bugs that may not have workarounds.

We often encourage competition because the end user stands to benefit. It's clear that Microsoft's renewed aggressiveness with Windows 8 is making the OS space more interesting than it has been for a few years now. I don't know that we're necessarily going to see an increased rate of switching/reverse switching as a result of Mountain Lion/Windows 8 but that's where all of this is heading. Microsoft wants to prevent and reverse any exodus to the Mac while Apple wants to grow its marketshare at Microsoft's expense. Even as the mobile revolution transpires it's clear that there's still room for innovation and competition in the more traditional notebook/desktop space.

Going into 2013 and beyond things do get more interesting however. The line between notebook and tablet will become even blurrier. If you could build something iPad-sized out of MacBook Air hardware what would it run? iOS or OS X? UI aside I think there are some very interesting options for OS convergence going forward.

Conclusions

Like most OS X updates, Mountain Lion combines visible new features with under-the-hood changes and improvements, which between them usually amount to an upgrade that is worth Apple's asking price for the majority of users. The changes you care about will vary from person to person, but based on what I've seen (both in the new features covered by other outlets or the changes I've mentioned above) it looks like there should be something here for most people, especially if you own multiple Macs or are in any way invested in iOS.

Those of you worried that Lion was the first step toward disallowing non-Mac App Store programs from running in OS X: that future has not come to pass, at least not yet. "Never" is a long time, but for now it appears that the Gatekeeper functionality is indicative of the way these things will be handled on Macs. The default settings may change, but power users can freely install anything they want on their systems, just as before.

The (admittedly smallish) audience of OS X Server users who were worried that Lion Server was a step toward dumbing the servers down and stripping out features: it looks like your fears may be more justified, depending on which services you use. Apple seems focused on maintaining a core set of technologies like Mail, NetBoot, Messages, Open Directory, Profile Manager, File Sharing, and others, but by (apparently) removing more enterprise-centric features like DHCP from OS X Server, the company seems to be admitting that its servers are typically used in conjunction with other Windows and/or Linux boxes that supply the network's backbone (which, at least in my experience as an IT admin, has tended to be true).

At this early point in the development process, the conclusions I've made here are the only ones I feel comfortable making. Keeping in mind that all of this is subject to change, have at it in the comments section.